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

[Avi Kivity <avi@redhat.com>]

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.

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

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.

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