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

[Jan Kiszka]

On 2011-10-17 13:25, Avi Kivity wrote:
> 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.

Practically, that may work. I just wanted to avoid searching. And for
static routes (irqfd, device assigment) you still need caches anyway, so
I decided to use them consistently.

Jan

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