On Fri, 2013-06-21 at 00:03 -0600, Alex Williamson wrote: > On Fri, 2013-06-21 at 15:12 +1000, Benjamin Herrenschmidt wrote: > > On Thu, 2013-06-20 at 22:46 -0600, Alex Williamson wrote: > > > Maybe you could add a device parameter to kvm_irqchip_add_msi_route so > > > that it can be implemented on POWER without this pci_bus_map_msi > > > interface that seems very unique to POWER. Thanks, > > > > You mean unique to all non-x86 ? :-) > > > > I believe almost everybody eventually turn MSIs into "normal" > > interrupts... > > > > Most often than not, the logic to do so is in the PCI Host Bridge. > > > > The whole concept of passing the message address/data accross the > > user/kernel interface is an x86 crackpotery but as is the entire > > remapping/routing layer so ... :-) > > Regardless, this is exactly what kvm_irqchip_add_msi_route does. It > says, here's an MSIMessage, give me an IRQ that sends that.
Yes, and in our case, what happens is that the guest said to use "I want an MSI", we picked up an IRQ, and made up a message for it :-) The actual message address/data we use is a complete invention that only exists within qemu. So here we need to basically turn it back into an IRQ, which we might be able to do by ... just making the message (or part of the address) be the IRQ number or something like that. > In the x86 > case, that means pick a free IRQ and program it to send that MSIMessage > when we hit the irqfd. In the case of POWER it means lookup which IRQ > gets fired by that MSIMessage and return it. In a non-accelerated QEMU > case I'd think msi_notify() would write the MSIMessage to this IRQ > remapper device and let it toggle the next qemu_irq down the line. If > we ever add an IOMMU based IRQ remapper to the x86 model, we'd need > something similar. Thanks, Ben.
