> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com] > Sent: Monday, June 19, 2017 6:15 PM > > On 19/06/17 08:54, Bharat Bhushan wrote: > > Hi Eric, > > > > I started added replay in virtio-iommu and came across how MSI interrupts > with work with VFIO. > > I understand that on intel this works differently but vsmmu will have same > requirement. > > kvm-msi-irq-route are added using the msi-address to be translated by > viommu and not the final translated address. > > While currently the irqfd framework does not know about emulated > iommus (virtio-iommu, vsmmuv3/vintel-iommu). > > So in my view we have following options: > > - Programming with translated address when setting up kvm-msi-irq-route > > - Route the interrupts via QEMU, which is bad from performance > > - vhost-virtio-iommu may solve the problem in long term > > > > Is there any other better option I am missing? > > Since we're on the topic of MSIs... I'm currently trying to figure out how > we'll handle MSIs in the nested translation mode, where the guest manages > S1 page tables and the host doesn't know about GVA->GPA translation. > > I'm also wondering about the benefits of having SW-mapped MSIs in the > guest. It seems unavoidable for vSMMU since that's what a physical system > would do. But in a paravirtualized solution there doesn't seem to be any > compelling reason for having the guest map MSI doorbells. These addresses > are never accessed directly, they are only used for setting up IRQ routing > (at least on kvmtool). So here's what I'd like to have. Note that I > haven't investigated the feasibility in Qemu yet, I don't know how it > deals with MSIs. > > (1) Guest uses the guest-physical MSI doorbell when setting up MSIs. For > ARM with GICv3 this would be GITS_TRANSLATER, for x86 it would be the > fixed MSI doorbell. This way the host wouldn't need to inspect IOMMU > mappings when handling writes to PCI MSI-X tables. >
What do you mean by "fixed MSI doorbell"? PCI MSI-X table is part of PCI MMIO bar. Accessing to it is just a memory virtualization issue (e.g. trap by KVM and then emulated in Qemu) on x86. It's not a IOMMU problem. I guess you may mean same thing but want to double confirm here given the terminology confusion. Or do you mean the interrupt triggered by IOMMU itself? Thanks Kevin
