Re: [PATCH 09/10] KVM: Enable MSI for device assignment

[Sheng Yang <yasker@gmail.com>]

On Tue, Nov 04, 2008 at 03:32:49PM +0200, Avi Kivity wrote:
> Sheng Yang wrote:
>> One question here: did the architectures other than X86 and IA64 need
>> dispatch MSI support?  
>
> s390 doesn't.  ppc may, one day in the future.  Not now I think.

OK, so reuse is enough for today.
>
>> If so, I am afraid reuse assigned_device_msi_dispatch
>> (or similar solution) won't be elegant (though I already lean toward a arch
>> specific dispatch function).
>>
>> I am not familiar with virtio-pci and how it works, it would be good if
>> it can be illustrated a little more. 
>
> For this context, it's just a pci device.  qemu calls KVM_IRQ_LINE to  
> inject an irq, and the pci layer in the guest delivers the irq to the  
> virtio-pci driver.

Got it.
>
> In fact, it's not just for pci.  We could msi-enable e1000 and get  
> improved performance there as well.

E1000? Don't understand... Sounds like INTx->MSI...
>
>> But I guess what you means is only set
>> gsi can result in kvm_set_irq() deliver the MSI correctly. I think this can
>> be done. Associating gsi with guest_msi_addr and guest_msi_data in a linked
>> list, for gsi >= IOAPIC_PINS,
> Let's say, (gsi >> 24) == 1.  That gives us 16M potential MSIs.

Confused... GSI become a bitmap?
>
>>  kvm_set_irq() checked the list and deliver the
>> interrupt. Of course, some lock should be taken to maintain the list, maybe
>> kvm->lock in first step as we used for kvm_set_irq (kvm->lock become more
>> and more bigger...).
>>   
>
> I think kvm_set_irq() already takes kvm->lock.

Yes. So I means maybe we can improve the granularity of the lock in interrupt
handling part in the future.

--
regards
Yang, Sheng
>
> -- 
> error compiling committee.c: too many arguments to function
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html