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

[Avi Kivity <avi@redhat.com>]

On 04/23/2012 06:55 PM, Jan Kiszka wrote:
> On 2012-04-23 17:32, Avi Kivity wrote:
> > 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?
>
> As I explained a few times: We avoid taking the lengthy path in
> userspace, GSI exhaustion, sporadic routing flushes etc. when running on
> a modern kernel. The "ugly" part in userspace is rather small as we can
> refrain from optimizing it. Specifically we do not need to touch QEMU
> all over the MSI path just for KVM.

Okay, I guess waiting for a grace period in order to queue an interrupt
is excessive.

> > 
> > 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).
>
> Why would some MSI-only injection IOCTL be problematic for a syscall
> model? 

It increases the number of syscalls, and doesn't bound it if new
interrupt types (like MSI with source information) becomes available.

However, this thinking shouldn't influence the ioctl interface too much.

> I rather suspect the generic IOCTL may have some limitations as
> it /might/ be used for mixing broadcasts with solely VCPU-targeted IRQ
> injections one day, on some arch.

Well we can do that now, with either interface, since MSIs can be
unicast or multicast.

> > 
> > 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.
>
> We will need hierarchical dispatching, using additional source
> information. But that information is totally unrelated to the pseudo GSI
> currently used by KVM for the final delivery step to the APIC bus. In
> fact, the whole message content can be unrelated as it can be modified
> and even coalesced with other sources along its way to the KVM injection
> API.

Depends on whether we emulate interrupt remapping in the kernel or
userspace.

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