Re: [PATCH v4] kvm: Use a bitmap for tracking used GSIs

From: Avi Kivity <avi@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Alex Williamson <alex.williamson@hp.com>,
	kvm@vger.kernel.org, sheng.yang@intel.com
Subject: Re: [PATCH v4] kvm: Use a bitmap for tracking used GSIs
Date: Mon, 18 May 2009 16:55:30 +0300	[thread overview]
Message-ID: <4A1168D2.7090709@redhat.com> (raw)
In-Reply-To: <20090518134504.GB23296@redhat.com>

Michael S. Tsirkin wrote:
> On Mon, May 18, 2009 at 03:33:20PM +0300, Avi Kivity wrote:
>   
>> Michael S. Tsirkin wrote:
>>     
>>>>> On the other hand, in MSI-X mask bit is mandatory, not optional
>>>>> so we'll have to support it for assigned devices at some point.
>>>>>
>>>>> If we are worried about speed of masking/unmasking MSI-X interrupts for
>>>>> assigned devices (older kernels used to mask them, recent kernels leave
>>>>> this to drivers) we will probably need to have MSI-X support in the
>>>>> kernel, and have kernel examine the mask bit before injecting the
>>>>> interrupt, just like real devices do.
>>>>>         
>>>>>           
>>>> Yes.
>>>>     
>>>>         
>>> Actually, if we do that, we'll need to address a race where a driver
>>> has updated the mask bit in the window after we tested it
>>> and before we inject the interrupt. Not sure how to do this.
>>>   
>>>       
>> The driver can't tell if the interrupt came first, so it's a valid race  
>> (real hardware has the same race).
>>     
>
> The driver for real device can do a read followed by sync_irq to flush
> out interrupts.
>   

If it generates the interrupt after masking it in the msi-x entry, we'll 
see it.  If it generates the interrupt before masking it, it may or may 
not receive the interrupt, even on real hardware.

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