On 12/06/2015 18:37, Alex Bennée wrote: > Emulated hardware state > ----------------------- > > Currently the hardware emulation has no protection against > multiple-accesses. However guest systems accessing emulated hardware > should be carrying out their own locking to prevent multiple CPUs > confusing the hardware. Of course there is no guarantee the there > couldn't be a broken guest that doesn't lock so you could get racing > accesses to the hardware. > > There is the class of paravirtualized hardware (VIRTIO) that works in > a purely mmio mode. Often setting flags directly in guest memory as a > result of a guest triggered transaction. > > DESIGN REQUIREMENTS: > > - Access to IO Memory should be serialised by an IOMem mutex
This should simply be the "big QEMU lock", which also protects the I/O subsystem. With BQL-free TCG (a subset of multi-threaded TCG), the code in qemu_mutex_lock_iothread that forces VCPUs to relinquish the mutex can be dropped. Paolo > - The mutex should be recursive (e.g. allowing pid to relock itself) > > IO Subsystem > ------------ > > The I/O subsystem is heavily used by KVM and has seen a lot of > improvements to offload I/O tasks to dedicated IOThreads. There should > be no additional locking required once we reach the Block Driver. > > DESIGN REQUIREMENTS: > > - The dataplane should continue to be protected by the iothread locks > > > References > ========== > > [1] > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/memory-barriers.txt > [2] http://thread.gmane.org/gmane.comp.emulators.qemu/334561 > [3] http://thread.gmane.org/gmane.comp.emulators.qemu/335297 > > >
