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
