[Qemu-devel] Re: [RFC PATCH 4/5] APIC/IOAPIC EOI callback

[Michael S. Tsirkin]

On Sun, Jul 11, 2010 at 01:21:18PM -0600, Alex Williamson wrote:
> On Sun, 2010-07-11 at 21:54 +0300, Michael S. Tsirkin wrote:
> > On Sun, Jul 11, 2010 at 09:30:59PM +0300, Avi Kivity wrote:
> > > On 07/11/2010 09:26 PM, Alex Williamson wrote:
> > > >On Sun, 2010-07-11 at 21:14 +0300, Avi Kivity wrote:
> > > >>On 07/11/2010 09:09 PM, Alex Williamson wrote:
> > > >>>For device assignment, we need to know when the VM writes an end
> > > >>>of interrupt to the APIC, which allows us to de-assert the interrupt
> > > >>>line and clear the DisINTx bit.  Add a new wrapper for ioapic
> > > >>>generated interrupts with a callback on eoi and create an interface
> > > >>>for drivers to be notified on eoi.
> > > >>>
> > > >>You aren't going to get this with kvm's in-kernel irqchip, so we need a
> > > >>new interface there.
> > > >Registering an eventfd for the eoi seems like a reasonable alternative.
> > > 
> > > I'm worried about that racing (with what?)
> > 
> > With device asserting the interrupt?
> > Need to make sure that all possible scenarious work well:
> > 
> >     device asserts interrupt
> >     driver clears interrupt
> >     device asserts interrupt
> >     eoi
> > 
> >     device asserts interrupt
> >     driver clears interrupt
> >     eoi
> >     device asserts interrupt
> > 
> > etc
> > 
> > Not that I see issues, these are things we need to check.
> 
> I think those are all protected by host and qemu vfio drivers managing
> DisINTx.  The way I understand it to work now is:
> 
>       device asserts interrupt
>       interrupt lands in host vfio driver
>       host vfio sets DisINTx on the device
>       host vfio sends eventfd
>       eventfd lands in qemu vfio, does a qemu_set_irq
>         ... guest processes
>       guest writes eoi to apic, lands back in qemu vfio driver
>       qemu vfio deasserts qemu interrupt
>       qemu vfio clears DisINTx
> 
> So I don't think there's a race as long as ordering is sane for toggling
> DisINTx.  Thanks,
> 
> Alex
> 

What about threaded interrupts? I think (correct me if I am wrong)
that they work like this:

        device asserts interrupt
        guest disables interrupt
        eoi
        guest enables interrupt
        driver clears interrupt
        device asserts interrupt

If so, your code will clear DisINTx immediately which
will always get us another host interrupt:
performance will be hurt. I am also not sure
we'll not lose interrupts.

It seems we need to track interrupt disable/enable as well, and only
clear DisINTx after eoi with interrupts enabled.  Not sure what is the
interface for this.


-- 
MST