Re: [PATCH v2 0/9] qemu-kvm: Clean up and enhance MSI irqchip support

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Apr 27, 2011 at 05:01:09PM +0300, Avi Kivity wrote:
> On 04/27/2011 04:54 PM, Jan Kiszka wrote:
> >>>
> >>>  I was planning for a MSI short-path anyway. Also for TCG, it's pointless
> >>>  to go through lengthy stl_phys if we know it's supposed to be an MSI
> >>>  message.
> >>
> >>  I don't think tcg will see much benefit; the decoding path through
> >>  hw/apic.c isn't complicated.
> >
> >stl_phys itself is non-trivial, e.g. due to phys_page_find.
> 
> That is true.  But consider that MSI delivery has to emulate
> interrupt injection through the IDT...
> 
> >>
> >>  Maybe an intermediate solution is to move kvm_hpet_msi_update() (with a
> >>  neutral name) into msi.c and have hpet call it whenever things change.
> >>  So hpet.c isn't aware of kvm directly.
> >
> >Without caching, you need per-vector tracking to refresh or drop routes.
> >That's what the hooks are about.
> 
> Right, my proposal doesn't really change your code, it simply moves
> the kvm specific parts away from hpet.c.  Instead of a general
> cache, the caller is supposed to provide a unique KVMMsiMessage per
> msi vector, so there is no cache management.
> 
> >Intermediate solutions (like hacking msi.c now) are one thing. We also
> >have to know where we can go to long-term.
> 
> The really general case (allow generating an MSI via DMA, or allow
> the device to write to non-MSI addresses via MSI generation) needs
> the full blown cache.  But while I've seen these techniques actually
> used, I hope they're rare.

You have? What uses these?

As you pointed out earlier, we can make DMA to MSI work, slowly, by
using a single gsi per apic.
For the reverse, it's probably easiest to make it work by
handling MSI outside the APIC range as a store in the kvm
module in kernel.

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