qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [patch v4 00/16] push mmio dispatch out of big lock


From: Avi Kivity
Subject: Re: [Qemu-devel] [patch v4 00/16] push mmio dispatch out of big lock
Date: Mon, 29 Oct 2012 17:24:28 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1

On 10/25/2012 07:13 PM, Peter Maydell wrote:
> On 25 October 2012 18:07, Avi Kivity <address@hidden> wrote:
>> On 10/25/2012 04:04 PM, Peter Maydell wrote:
>>> Is there a clear up to date description somewhere of the design and
>>> locking strategy here somewhere? I'd rather not have to try to
>>> reconstitute it by reading the whole patchset...
>>
>> It was described somewhere in a document by Marcelo and myself.
>> Basically the goal is to arrive at
>>
>> address_space_write():
>>   rcu_read_lock()
>>   mr = lookup()
>>   mr->ref()
>>   rcu_read_unlock()
>>
>>   mr->dispatch()
>>
>>   mr->unref()
>>
>> This is the same strategy used in many places in the kernel.
> 
> Yes, but this is rather short on the details

Until Jan fleshes this out:

> (eg, does every
> device have its own lock, 

No, devices which are not modified will continue to use the BQL.

> what are we doing with irqs, 

Eventually they will gain fine-grained threading too.  Until then, they
will be protected by the big lock (and any device which calls any irq
APIs must hold it).

> how about
> dma from devices, etc etc).

DMA will be unlocked, if done to a device which has its own lock (same
as mmio).

> It's the details of the design I'd
> like to see described...


-- 
error compiling committee.c: too many arguments to function



reply via email to

[Prev in Thread] Current Thread [Next in Thread]