Re: [KVM PATCH v4 2/2] kvm: add support for irqfd via eventfd-notificationinterface
From: Avi Kivity
Date: Thu May 07 2009 - 11:26:24 EST
Gregory Haskins wrote:
This is my preferred option. For a virtio-net-server in the kernel,
we'd service its eventfd in qemu, raising and lowering the pci
interrupt in the traditional way.
But we'd still need to know when to lower the interrupt. How?
IIUC, isn't that usually device/subsystem specific, and out of scope of
the GSI delivery vehicle? For instance, most devices I have seen with
level ints have a register in their device register namespace for acking
the int.
Yes it is.
As an aside, this is what causes some of the grief in dealing
with shared interrupts like KVM pass-through and/or threaded-isrs:
There isn't a standardized way to ACK them.
So we'd need a side channel to tell userspace to lower the irq. Another
eventfd likely.
Note we don't support device assignment for devices with shared interrupts.
You may also see some generalization of masking/acking in things like
the MSI-X table. But again, this would be out of scope of the general
GSI delivery path IIUC.
I understand that there is a feedback mechanism in the ioapic model for
calling back on acknowledgment of the interrupt. But I am not sure what
is how the real hardware works normally, and therefore I am not
convinced that is something we need to feed all the way back (i.e. via
irqfd or whatever). In the interest of full disclosure, its been a few
years since I studied the xAPIC docs, so I might be out to lunch on that
assertion. ;)
Right, that ack thing is completely internal, used for catching up on
time drift, and for shutting down level triggered assigned interrupts.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/