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@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
