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. 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. 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 -- 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
