Re: [patch 2/4] KVM: move coalesced_mmio locking to its own device

From: Marcelo Tosatti <mtosatti@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: [patch 2/4] KVM: move coalesced_mmio locking to its own device
Date: Wed, 20 May 2009 12:13:03 -0300	[thread overview]
Message-ID: <20090520151303.GA14582@amt.cnet> (raw)
In-Reply-To: <4A1413C3.4020606@redhat.com>

On Wed, May 20, 2009 at 05:29:23PM +0300, Avi Kivity wrote:
> Marcelo Tosatti wrote:
>
>  
>
>>> So we have a function that takes a lock and conditionally releases it?
>>>     
>>
>> Yes, but it is correct: it will only return with the lock held in case
>> it returns 1, in which case its guaranteed ->write will be called (which
>> will unlock it).
>>
>> It should check the range first and/or use some smarter synchronization,
>> but one thing at a time.
>>   
>
> Yes it's correct but we'll get an endless stream of patches to 'fix' it  
> because it is so unorthodox.

Does it have to guarantee any kind of ordering in case of parallel
writes by distincting vcpus? This is what it does now (so if a vcpu
arrives first, the second will wait until the first is finished
processing).

I suppose that is the responsability of the guest (if it does MMIO
writes to a device in parallel it'll screwup in real HW too).

Because in such case, you can drop the mutex and protect only the kvm
data.