Re: [RFC PATCH] kvm: Extend irqfd to support level interrupts

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

On Sun, Jun 17, 2012 at 04:15:44PM -0600, Alex Williamson wrote:
> On Sun, Jun 17, 2012 at 3:38 PM, Alex Williamson
> <alex.williamson@redhat.com> wrote:
> > On Sun, 2012-06-17 at 21:44 +0300, Michael S. Tsirkin wrote:
> >> On Sat, Jun 16, 2012 at 10:34:39AM -0600, Alex Williamson wrote:
> >> > I'm looking for opinions on this approach.  For vfio device assignment
> >> > we minimally need a way to get EOIs from the in-kernel irqchip out to
> >> > userspace.  Getting that out via an eventfd would allow us to bounce
> >> > all level interrupts out to userspace, where we would de-assert the
> >> > device interrupt in qemu and unmask the physical device.  Ideally we
> >> > could deassert the interrupt in KVM, which allows us to send the EOI
> >> > directly to vfio.  To do that, we need to use a new IRQ source ID so
> >> > the guest sees the logical OR of qemu requested state and external
> >> > device state.
> >>
> >> Given that yopu want to involve userspace anyway, why insist on irqfd
> >> for this?  You can simply use KVM_IRQ_LINE_STATUS from qemu, no?
> >
> > Well, actually I'd like to have a way to bypass userspace, which the
> > combination of an irqfd + eventfd w/ deassert does.


Hmm but above you say
	> >> > Getting that out via an eventfd would allow us to bounce
	> >> > all level interrupts out to userspace, where we would de-assert the
	> >> > device interrupt in qemu and unmask the physical device.
so what is the plan?

>  I'm not quite sure
> > I understand how KVM_IRQ_LINE_STATUS would work for this.  AIUI, that
> > effectively gives us a way to post an interrupt AND let us know whether
> > it was masked, coalesced, or delivered.  So I'd have to poll by posting
> > a potentially spurious interrupt and if it was spurious unmask the
> > physical device and wait for a real interrupt?  What am I missing,
> > because that seems barely functional?  Thanks,
> 
> Just to clarify, setting the interrupt from qemu isn't a problem.  We
> can do that just like any other device.  The unique aspect is that we
> need to know when the guest has issued an EOI so that we can unmask
> the physical device interrupt and wait for it to fire again.  This is
> where I don't understand how KVM_IRQ_LINE_STATUS helps us.
> The minimal support I mention above just requires informing userspace
> about the EOI, then we can deassert and unmask from qemu.  That means
> we issue two more ioctl before we're enabled for the next interrupt.

Exactly.

> Rather than invent a new interface for a sub-optimal implementation,
> fixing irqfd to support level triggered interrupts is potentially more
> useful and I think this implementation is not specific to device
> assignment.  BTW, what happens with vhost use of irqfd when the guest
> runs out of MSI vectors?  Could it use this interface for that?
> Thanks,
> 
> Alex


Sure. OTOH this never was a real issue - if it was
we could teach Linux to share MSI interrupt.

-- 
MST