From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37105 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OcEqm-0004pq-3I for qemu-devel@nongnu.org; Fri, 23 Jul 2010 05:47:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OcEqk-0001qi-JE for qemu-devel@nongnu.org; Fri, 23 Jul 2010 05:47:27 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:55747) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OcEqk-0001qY-AX for qemu-devel@nongnu.org; Fri, 23 Jul 2010 05:47:26 -0400 Message-ID: <4C496547.7040107@web.de> Date: Fri, 23 Jul 2010 11:47:51 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Release of COREMU, a scalable and portable full-system emulator References: <438ED7C1-AD7C-4946-99D2-B0E9A91B8DF1@gmail.com> <6BBDD0C9-39D5-435C-8CD7-4E3DD8BAF57D@gmail.com> <4C472889.5000407@mail.berlios.de> <2FAAD29F-6C3E-4128-A6E1-46EE15AF80FA@gmail.com> <4C484105.5060607@siemens.com> <4C494A60.2040502@web.de> <1D54BA79-2AE5-40B3-813C-676529F1BA49@suse.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig85664569A8F5C79D4FBCB42D" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Chen Yufei , wang Tiger , Alexander Graf , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig85664569A8F5C79D4FBCB42D Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Stefan Hajnoczi wrote: > 2010/7/23 Alexander Graf : >> On 23.07.2010, at 09:53, Jan Kiszka wrote: >> >>> wang Tiger wrote: >>>> =D4=DA 2010=C4=EA7=D4=C222=C8=D5 =CF=C2=CE=E711:47=A3=ACStefan Hajno= czi =D0=B4=B5=C0=A3=BA >>>>> 2010/7/22 wang Tiger : >>>>>> In our implementation for x86_64 target, all devices except LAPIC = are >>>>>> emulated in a seperate thread. VCPUs are emulated in other thread= s >>>>>> (one thread per VCPU). >>>>>> By observing some device drivers in linux, we have a hypothethis t= hat >>>>>> drivers in OS have already ensured correct synchronization on >>>>>> concurrent hardware accesses. >>>>> This hypothesis is too optimistic. If hardware emulation code assu= mes >>>>> it is only executed in a single-threaded fashion, but guests can >>>>> execute it in parallel, then this opens up the possibility of race >>>>> conditions that malicious guests can exploit. There needs to be >>>>> isolation: a guest should not be able to cause QEMU to crash. >>>> In our prototype, we assume the guest behaves correctly. If hardware= >>>> emulation code can ensure atomic access(behave like real hardware), >>>> VCPUS can access device freely. We actually refine some hardward >>>> emulation code (eg. BMDMA, IOAPIC ) to ensure the atomicity of >>>> hardware access. >>> This approach is surely helpful for a prototype to explore the limits= =2E >>> But it's not applicable to production systems. It would create a huge= >>> source of potential subtle regressions for other guest OSes, >>> specifically those that you cannot analyze regarding synchronized >>> hardware access. We must play safe. >>> >>> That's why we currently have the global mutex. Its conversion can onl= y >>> happen step-wise, e.g. by establishing an infrastructure to declare t= he >>> need of device models for that Big Lock. Then you can start convertin= g >>> individual models to private locks or even smart lock-less patterns. >> But isn't that independent from making TCG atomic capable and parallel= ? At that point a TCG vCPU would have the exact same issues and interface= s as a KVM vCPU, right? And then we can tackle the concurrent device acce= ss issues together. >=20 > An issue that might affect COREMU today is core QEMU subsystems that > are not thread-safe and used from hardware emulation, for example: >=20 > cpu_physical_memory_read/write() to RAM will use qemu_get_ram_ptr(). > This function moves the found RAMBlock to the head of the global RAM > blocks list in a non-atomic way. Therefore, two unrelated hardware > devices executing cpu_physical_memory_*() simultaneously face a race > condition. I have seen this happen when playing with parallel > hardware emulation. Those issues need to be identified and, in a first step, worked around by holding dedicated locks or just the global mutex. Maybe the above conflict can also directly be resolved by creating per-VCPU lookup lists (likely more efficient than tapping on other VCPU shoes by constantly reordering a global list). Likely a good example for a self-contained preparatory patch. However, getting concurrency right is tricky enough. We should really be careful with turning to much upside down in a rush. Even if TCG may have some deeper hooks into the device model or thread-unsafe core parts than KVM, parallelizing it can and should remain a separate topic. And we also have to keep an eye on performance if a bit less than 255 VCPUs shall be emulated. Jan --------------enig85664569A8F5C79D4FBCB42D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkxJZUsACgkQitSsb3rl5xTlagCg67mTmZ3229R0vA2fcnAqlKpM fN0An0psfxMy79hmW5Wd8FUihGBKoqpq =wokk -----END PGP SIGNATURE----- --------------enig85664569A8F5C79D4FBCB42D--