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

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2012-04-03 18:54, Avi Kivity wrote:
> 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).

If you are concerned about performance in this path, wouldn't a DMA
interface for MSI injection be counterproductive?

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux