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

[Avi Kivity <avi@redhat.com>]

On 04/03/2012 07:47 PM, Jan Kiszka wrote:
> > 
> > so we have a single ioctl for all interrupt handling.  This allows
> > eventual removal of the line-oriented ioctls.
> > 
> > The other alternative is to have a dma interface, similar to the kvm_run
> > mmio interface but with the kernel acting as destination.  The advantage
> > here is that we can handle dma from a device to any kernel-emulated
> > device, not just the APIC MSI range.  A downside is that we can't return
> > values related to interrupt coalescing.
>
> Due to lacking injection feedback, I'm in favor of option 1. Will have a
> look.

I wonder if we can create a side channel for it.  Lack of a kernel DMA
API is a hole in the current code, though we haven't been bitten by it
yet.  An example is a guest that is swapping its own page tables; right
now the shadow mmu doesn't notice those writes (when the page tables are
swapped in) and will deliver incorrect results.  Of course no guest does
that, so it doesn't happen in practice.

> > 
> > A performance note: delivering an interrupt needs to search all vcpus
> > for an APIC ID match.  The previous plan was to cache (or pre-calculate)
> > this lookup in the irq routing table.  Now it looks like we'll need a
> > separate cache for this.
>
> As this is non-existent until today, we don't regress here. And it can
> still be added on top later on, transparently.

Yes, it's just a note, not an objection.  The cache lookup will be
slower than the gsi lookup (hash table vs. array) but still O(1) vs. the
current O(n).

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