Messages in this thread | | | Date | Thu, 07 May 2009 18:26:05 +0300 | From | Avi Kivity <> | Subject | Re: [KVM PATCH v4 2/2] kvm: add support for irqfd via eventfd-notification interface |
| |
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
| |