[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RFC Multi-threaded TCG design document
From: |
Alex Bennée |
Subject: |
Re: [Qemu-devel] RFC Multi-threaded TCG design document |
Date: |
Wed, 17 Jun 2015 16:57:01 +0100 |
Paolo Bonzini <address@hidden> 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