Re: [PATCH v4 3/9] KVM: Clear assigned guest IRQ on release

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Nov 10, 2010 at 08:53:35AM +0200, Avi Kivity wrote:
> On 11/09/2010 08:36 PM, Alex Williamson wrote:
> >>
> >>  Note: all this kvm_set_irq(..., [01]) is incorrect as it doesn't account
> >>  for polarity.  Currently the qemu-emulated chipset uses level high pci
> >>  interrupts, but that's not a given from kvm's point of view.
> >>
> >>  I think vfio fixes this by only routing msi interrupts via the kernel,
> >>  and routing level interrupts through userspace, which can adjust
> >>  polarity.  Alex/Michael?
> >
> >The latest patches will route legacy interrupts via irqfd if available
> >too.  We do have the issue that KVM pulses interrupts injected this way,
> >but it seems to work nonetheless.
> 
> That doesn't sound too good.

It's more than luck that it works: there is a backend
device that keeps the interrupt asserted, if driver did not
handle the interrupt but the OS did ack it, we will unmask
the interrupt, get another one from the device
(or just notice status bit is set) and send another pulse.

Whether all this improves or hurts performance, or whether
some guest might notice the difference, I don't know.
So maybe pulsing the interrupt is actually a good thing?
Anyone has any theories?

What I think is broken, is
1. interrupt sharing, as irqfds use the userspace id instead of
   a per-device id.
2. emulated devices as there's no one to reassert the interrupt.


> >I was thinking about proposing a
> >level flag for set_irqfd to only set it, allowing the ack notifier to
> >deassert it.  Perhaps we also need a flag to toggle the polarity.
> 
> Or maybe irqfd is not up to this task.
> 
> I'd rather stick with the ordinary ioctls for this until proven
> they're too slow.  By proven, I mean a userspace irq forwarding
> implementation that doesn't suck like we it does now (can be just a
> prototype).
> 
> -- 
> I have a truly marvellous patch that fixes the bug which this
> signature is too narrow to contain.
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html