2010/7/23 Alexander Graf <ag...@suse.de>: > > On 23.07.2010, at 09:53, Jan Kiszka wrote: > >> wang Tiger wrote: >>> 在 2010年7月22日 下午11:47，Stefan Hajnoczi <stefa...@gmail.com> 写道： >>>> 2010/7/22 wang Tiger <tigerwang1...@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. > > 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.
An issue that might affect COREMU today is core QEMU subsystems that are not thread-safe and used from hardware emulation, for example: 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. Tiger: If you are only locking the hardware thread for ARM target, your hardware emulation is not safe for other targets. Have I missed something in the COREMU patch that defends against this problem? Stefan
