[Qemu-devel] Re: Release of COREMU, a scalable and portable full-system emulator

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]

wang Tiger wrote:
> 在 2010年7月22日 下午11:47，Stefan Hajnoczi <stefanha@gmail.com> 写道：
>> 2010/7/22 wang Tiger <tigerwang1986@gmail.com>:
>>> 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.
> 
> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]