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

[wang Tiger]

在 2010年7月23日 下午3:53，Jan Kiszka <address@hidden> 写道：
> 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.
>
> Jan
>
>
I agree with you on this point. The approach we used is really helpful
for a research prototype. But it needs a lot of work to make it
applicable to production systems.
Its my pleasure if we can tackle this issue togethor.

-- 
Zhaoguo Wang, Parallel Processing Institute, Fudan University

Address: Room 320, Software Building, 825 Zhangheng Road, Shanghai, China

address@hidden
http://ppi.fudan.edu.cn/zhaoguo_wang