Re: [Qemu-devel] RFC Multi-threaded TCG design document

["Alex Bennée" <alex.bennee@linaro.org>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> 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)

Paolo,

But would there be a risk is we make the BQL recursive?

I had to do this because the iomem accesses either side of a virt-io
transaction would deadlock otherwise. 


-- 
Alex Bennée