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

[Avi Kivity <avi@redhat.com>]

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.

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