Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips

[Avi Kivity <avi@redhat.com>]

On 10/24/2011 02:06 PM, Jan Kiszka wrote:
> On 2011-10-24 13:09, Avi Kivity wrote:
> > On 10/24/2011 12:19 PM, Jan Kiszka wrote:
> >>>
> >>> With the new feature it may be worthwhile, but I'd like to see the whole
> >>> thing, with numbers attached.
> >>
> >> It's not a performance issue, it's a resource limitation issue: With the
> >> new API we can stop worrying about user space device models consuming
> >> limited IRQ routes of the KVM subsystem.
> >>
> > 
> > Only if those devices are in the same process (or have access to the
> > vmfd).  Interrupt routing together with irqfd allows you to disaggregate
> > the device model.  Instead of providing a competing implementation with
> > new limitations, we need to remove the limitations of the old
> > implementation.
>
> That depends on where we do the cut. Currently we let the IRQ source
> signal an abstract edge on a pre-allocated pseudo IRQ line. But we
> cannot build correct MSI-X on top of the current irqfd model as we lack
> the level information (for PBA emulation). *) So we either need to
> extend the existing model anyway -- or push per-vector masking back to
> the IRQ source. In the latter case, it would be a very good chance to
> give up on limited pseudo GSIs with static routes and do MSI messaging
> from external IRQ sources to KVM directly.

Good point.

>
> But all those considerations affect different APIs than what I'm
> proposing here. We will always need a way to inject MSIs in the context
> of the VM as there will always be scenarios where devices are better run
> in that very same context, for performance or simplicity or whatever
> reasons. E.g., I could imagine that one would like to execute an
> emulated IRQ remapper rather in the hypervisor context than
> "over-microkernelized" in a separate process.

Right.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.