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.
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
