Re: [KVM PATCH v4 2/2] kvm: add support for irqfd via eventfd-notification interface

Avi Kivity
2009-05-07T15:26:23Z

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