On Wed, Feb 17, 2016 at 08:46:18PM +0100, Paolo Bonzini wrote: > > > On 17/02/2016 11:25, Peter Xu wrote: > > This patch extended the current PCI IOMMU functions into operation list, > > one new op is added to do interrupt remapping. > > > > Currently it is not working since int_remap is always NULL. It only > > provide a interface to extend PCI MSI to support interrupt remapping in > > the future. > > > > One helper function pci_setup_iommu_ops() is introduced. We can use this > > instead of the origin pci_setup_iommu() one to extend interrupt > > remapping on specific platform. > > For MSI, I think interrupt remapping can be done directly in the IOMMU > MemoryRegion. You can just overlay a new MemoryRegion on top of the > IOMMU region where MSIs are sent (that's around 0xFEE00000, I don't > remember where exactly). It will catch interrupts sent by the device, > remap them and forward them to the right interrupt destination in the host.
Yes, it should be 0xfee00000. I'd say this is a much better idea, so that I can leverage current memory region codes and avoid touching PCI at all. If the work is in iommu part, I think I can send my next RFC with basic IR together next time. > > I'm not sure about INTX interrupts, but I think that the host kernel > remaps them simply by virtualizing the IOAPIC's redirection table. Yes, what I understand is that, IOAPIC is handling all INTX interrupts. To remap these interrupts, we just need a translation for the IOAPIC IRQ table entries before the interrupts are delivered to APIC bus. There will need some code change in ACPI too to enumerate the IOAPIC device in DMAR region, so that we can declare that "this IOMMU owns the default IOAPIC". If so, I can call vtd_* function in ioapic_service() directly right? IIUC IOAPIC should be intel-specific too? Thanks! Peter > > Paolo
