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

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-04-27 15:39, Avi Kivity wrote:
> On 04/27/2011 04:31 PM, Jan Kiszka wrote:
>>>  A hash table is indeed overcomplicated for this.
>>>
>>>  How about a replacement for stl_phys() for the MSI case:
>>>
>>>  -             stl_phys(timer->fsb>>  32, timer->fsb&  0xffffffff);
>>>  +           msi_stl_phys(timer->fsb>>  32, timer->fsb&  0xffffffff,
>>>  &timer->msi_cache);
>>>
>>>  msi_stl_phys(target_phys_addr_t addr, uint32_t data, MSICache *cache)
>>>  {
>>>       if (kvm_msi_enabled()&&  addr&  MSI_ADDR_MASK == msi_base_addr) {
>>>            if (cache->addr != addr || cache->data != data) {
>>>                kvm_update_msi_cache(cache, addr, data);
>>>            }
>>>            kvm_irq_line(cache->gsi, 1);
>>>            kvm_irq_line(cache->gsi, 0);
>>>            return;
>>>       }
>>>       stl_phys(addr, data);
>>>  }
>>
>> 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.

> 
>>>  but at least it means that devices don't need significant
>>>  change for kvm support.  We could also allocate a single gsi for use in
>>>  hw/apic.c so hacks like using DMA to generate an MSI will work (will be
>>>  slow, though).
>>
>> Needs some thoughts, maybe it will work. Though, it's not yet clear to
>> me if we can drop the kvm hooks from msi/msix.c and still support
>> vhost/dev-assignment this way. Just to keep hpet.c cleaner, I don't
>> think it's worth the effort.
> 
> Right.  Do we have other users of MSI besides PCI?

And HPET? Not yet. IOMMU will become another user. Maybe future chipsets
will include more non-PCI devices that issue MSIs.

> 
> 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.

Intermediate solutions (like hacking msi.c now) are one thing. We also
have to know where we can go to long-term.

Jan

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