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

[Alexander Graf]

On 23.07.2010, at 09:53, Jan Kiszka wrote:

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

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 interfaces as a KVM vCPU, 
right? And then we can tackle the concurrent device access issues together.


Alex