Re: [Qemu-devel] [RFC][PATCH 11/45] msi: Factor out delivery hook

[Avi Kivity <avi@redhat.com>]

On 10/17/2011 01:15 PM, Jan Kiszka wrote:
> On 2011-10-17 12:56, Avi Kivity wrote:
> > On 10/17/2011 11:27 AM, Jan Kiszka wrote:
> >> So far we deliver MSI messages by writing them into the target MMIO
> >> area. This reflects what happens on hardware, but imposes some
> >> limitations on the emulation when introducing KVM in-kernel irqchip
> >> models. For those we will need to track the message origin.
> > 
> > Why do we need to track the message origin?  Emulated interrupt remapping?
>
> The origin holds the routing cache which we need to track if the message
> already has a route (and that without searching long lists) and to
> update that route instead of add another one.

Okay, having read more of the code I understand this better.  The
approach of providing an explicit cache entry, while more intrusive, is
simpler (at least, without std::unordered_map).  However you do need
destructors for the cache to let the core know that it can't reference
it anymore.


>
> > 
> > 
> > Not sure what the gain is from intercepting the msi just before the
> > stl_phys() vs. in the apic handler.
>
> APIC is x86-specific, MSI is not. I think Xen will also want to make use
> of this hook. I originally though of using it for the KVM in-kernel
> models as well, but I will now establish a callback at APIC-level
> (upstream will look differently from qemu-kvm in this regard).
>

But you still have to handle it the the platform interrupt controller
(or whatever processes msi messages) since you can still DMA there.  So
you don't get away from doing it there anyway.

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