From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49512 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OcD3o-0003Tg-W0 for qemu-devel@nongnu.org; Fri, 23 Jul 2010 03:52:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OcD3o-0000Ax-04 for qemu-devel@nongnu.org; Fri, 23 Jul 2010 03:52:48 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:43017) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OcD3n-0000Ai-MW for qemu-devel@nongnu.org; Fri, 23 Jul 2010 03:52:47 -0400 Message-ID: <4C494A60.2040502@web.de> Date: Fri, 23 Jul 2010 09:53:04 +0200 From: Jan Kiszka MIME-Version: 1.0 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> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig554B8068B392FD0E7AF3784D" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: Release of COREMU, a scalable and portable full-system emulator List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: wang Tiger Cc: Stefan Hajnoczi , Chen Yufei , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig554B8068B392FD0E7AF3784D Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable wang Tiger wrote: > =D4=DA 2010=C4=EA7=D4=C222=C8=D5 =CF=C2=CE=E711:47=A3=ACStefan Hajnoczi= =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 threads >>> (one thread per VCPU). >>> By observing some device drivers in linux, we have a hypothethis that= >>> drivers in OS have already ensured correct synchronization on >>> concurrent hardware accesses. >> This hypothesis is too optimistic. If hardware emulation code assumes= >> 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. >=20 > 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. 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 only happen step-wise, e.g. by establishing an infrastructure to declare the need of device models for that Big Lock. Then you can start converting individual models to private locks or even smart lock-less patterns. Jan --------------enig554B8068B392FD0E7AF3784D 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 iEYEARECAAYFAkxJSmsACgkQitSsb3rl5xRrKACffAQplPo7llFosujOxSpSAPff JmEAoKCIH+WZQcLI5K2LeCYJtoNj+l2E =Z+L1 -----END PGP SIGNATURE----- --------------enig554B8068B392FD0E7AF3784D--