Re: [PATCH 2/3] virtio ring implementation

[Dor Laor <dor.laor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

Rusty Russell wrote:
> On Tue, 2007-09-25 at 19:15 +0200, Dor Laor wrote:
>   
>> At the moment it's not good enough, there is a potential race were the
>> guest optimistically turn off
>> the VRING_AVAIL_F_NO_INTERRUPT in the vring_restart and afterwards
>> finds there are more_used so
>> it consume them in the poll function. 
>> If in the middle, packets arrive the host will see the flag is off and
>> send irq.
>> In that case the above irq handler will report IRQ_NONE.
>>     
>
> Good point.  On the one hand, reporting IRQ_NONE occasionally is not
> fatal.  On the other, it'd be nice to get this right.
>
>   
>> It's also not trivial to cancel the optimistic approach in the restart
>> function since then there might be another race
>> that will result in missing irq reaching the guest.
>>     
>
> I did it optimistically because otherwise we need two barriers (and
> still have a window).
>
>   
>> I'll try to think of something better than a hypercall for switching
>> irq on/off.
>>     
>
> Erk.  That would be v. bad...
>   
Actually double barrier will satisfy non-shared irq lines and will 
report irq handling right.
The more complex scenario is shared irqs (pci...), since several devices 
are raising the irq line (level triggered)
in the same time, while the tap add receive packets it always leaves a 
potential race for irq handled return
value. So seems like we better not have shared irq and if only if shared 
irq is a must we should do the
naughty naughty things.

If returning IRQ_NONE once in a while is not too bad (including the 
matching windows implementation)
then there is no issue.
Dor.
 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/