Re: [Qemu-devel] [RFC][PATCH 12/45] msi: Introduce MSIRoutingCache

[Avi Kivity]

On 10/17/2011 01:19 PM, Jan Kiszka wrote:
> > IMO this needlessly leaks kvm information into core qemu.  The cache
> > should be completely hidden in kvm code.
> > 
> > I think msi_deliver() can hide the use of the cache completely.  For
> > pre-registered events like kvm's irqfd, you can use something like
> > 
> >   qemu_irq qemu_msi_irq(MSIMessage msg)
> > 
> > for non-kvm, it simply returns a qemu_irq that triggers a stl_phys();
> > for kvm, it allocates an irqfd and a permanent entry in the cache and
> > returns a qemu_irq that triggers the irqfd.
>
> See my previously mail: you want to track the life-cycle of an MSI
> source to avoid generating routes for identical sources. A messages is
> not a source. Two identical messages can come from different sources. So
> we need a separate data structure for that purpose.
>

Yes, I understand this now.

Just to make sure I understand this completely:  a hash table indexed by
MSIMessage in kvm code would avoid this?  You'd just allocate on demand
when seeing a new MSIMessage and free on an LRU basis, avoiding pinned
entries.

I'm not advocating this (yet), just want to understand the tradeoffs.

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