On Sun, Jun 17, 2012 at 04:15:44PM -0600, Alex Williamson wrote:
> On Sun, Jun 17, 2012 at 3:38 PM, Alex Williamson
> <[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
