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

[Marcelo Tosatti <mtosatti@redhat.com>]

On Sun, May 24, 2009 at 05:04:52PM +0300, Avi Kivity wrote:
> Marcelo Tosatti wrote:
>> Get rid of kvm->lock dependency on coalesced_mmio methods. Use an  
>> atomic variable instead to guarantee only one vcpu is batching
>> data into the ring at a given time.
>>
>> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>>
>> Index: kvm-irqlock/virt/kvm/coalesced_mmio.c
>> ===================================================================
>> --- kvm-irqlock.orig/virt/kvm/coalesced_mmio.c
>> +++ kvm-irqlock/virt/kvm/coalesced_mmio.c
>> @@ -26,9 +26,12 @@ static int coalesced_mmio_in_range(struc
>>  	if (!is_write)
>>  		return 0;
>>  -	/* kvm->lock is taken by the caller and must be not released before
>> -         * dev.read/write
>> -         */
>> +	/*
>> + 	 * Some other vcpu might be batching data into the ring,
>> + 	 * fallback to userspace. Ordering not our problem.
>> + 	 */
>> +	if (!atomic_add_unless(&dev->in_use, 1, 1))
>> +		return 0;
>>    
>
> Ordering with simultaneous writes is indeed not our problem, but the  
> ring may contain ordered writes (even by the same vcpu!)

You mean writes by a vcpu should maintain ordering even when that vcpu
migrates to a different pcpu? 

The smp_wmb in coalesced_write guarantees that.

> Suggest our own lock here.  in_use is basically a homemade lock, better  
> to use the factory made ones which come with a warranty.

The first submission had a mutex but was considered unorthodox. Although
i agree with your argument made then, i don't see a way around that.

Some pseudocode please? 

Agree with the suggestion on patch 3, will fix the commentary on
kvm_host.h.