Re: [PATCH] KVM: Introduce generic interrupt injection for in-kernel irqchips

[Avi Kivity <avi@redhat.com>]

On 04/10/2012 09:30 PM, Jan Kiszka wrote:
> Currently, MSI messages can only be injected to in-kernel irqchips by
> defining a corresponding IRQ route for each message. This is not only
> unhandy if the MSI messages are generated "on the fly" by user space,
> IRQ routes are a limited resource that user space has to manage
> carefully.
>
> By providing a direct injection path, we can both avoid using up limited
> resources and simplify the necessary steps for user land. This path is
> provide in a way that allows for use with other interrupt sources as
> well. Besides MSIs also external interrupt lines can be manipulated
> through this interface, obsoleting KVM_IRQ_LINE_STATUS.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>
> This picks up Avi's first suggestion as I still think it is the better
> option to provide a direct MSI injection channel.

My main objection to the previous patch was that it's not needed; qemu
has to work with older kernels that have neither this nor the other
patch.  Given that, why do anything further?  It won't be cleaner
because the ugly path will remain for compatibility.

Is there any concrete problem that this solves, that cannot be solved by
a pure (but ugly) user space solution?

wrt the patch itself, it seems fine.  I have to agree that the
single-purpose ioctl looks cleaner (but may be less suitable for a
syscall based API).

Just to add some confusion: is this future proof wrt iommu/interrupt
remapping emulation?  If you have a single iommu that intercepts all of
the MSI space then there's no problem, but if there are multiple iommus,
or if some devices are "in front of" the iommu, then we need to identify
the source of the message as well.  So we'd need an MBZ field for MSI
injection, which can later be filled with the source ID.

-- 
error compiling committee.c: too many arguments to function