On Mon, 2012-06-18 at 08:51 +0300, Michael S. Tsirkin wrote: > On Sun, Jun 17, 2012 at 03:38:57PM -0600, Alex Williamson 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. > > Above you said "bounce all level interrupts out to userspace"? And then go on to discuss what I'd rather implement instead. > > 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, > > > > Alex > > Sorry if I did not make this clear. You still need to add a way to pass > EOI writes out to userspace. But that's all you need: once > userspace gets EOI events for specific GSIs, it can control IRQ level from userspace > in the same way it does it for emulated devices: > wake up on EOI, poll all devices, if no interrupt asserted - > clear IRQ line and unmask IRQ in assigned device. Right, this is all we need for a completely mediocre implementation. > Above is with plain exit to userspace rather than eventfd, > though eventfd is also possible but then you need to clear > irq level in kernel and re-assert from userspace later - > I think it's ok but need to think about possible races. And this is more along the lines of what I'm attempting to do, using a new irq source id so that the irqchip handles taking the OR of inputs. We can always reassert the interrupt if the de-assert was unnecessary. I thought it more beneficial to optimize for the interrupt being handled. 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
