Hi Jason Thanks, its now clear what you had mentioned earlier. I had couple questions/clarifications below. Thanks for working through this. On Fri, Nov 06, 2020 at 08:12:07PM -0400, Jason Gunthorpe wrote: > On Fri, Nov 06, 2020 at 03:47:00PM -0800, Dan Williams wrote: > > > Also feel free to straighten me out (Jason or Ashok) if I've botched > > the understanding of this. > > It is pretty simple when you get down to it. > > We have a new kernel API that Thomas added: > > pci_subdevice_msi_create_irq_domain() > > This creates an IRQ domain that hands out addr/data pairs that > trigger interrupts. > > On bare metal the addr/data pairs from the IRQ domain are programmed > into the HW in some HW specific way by the device driver that calls > the above function. > > On (kvm) virtualization the addr/data pair the IRQ domain hands out > doesn't work. It is some fake thing. Is it really some fake thing? I thought the vCPU and vector are real for a guest, and VMM ensures when interrupts are delivered they are either. 1. Handled by VMM first and then injected to guest 2. Handled in a Posted Interrupt manner, and injected to guest when it resumes. It can be delivered directly if guest was running when the interrupt arrived. > > To make this work on normal MSI/MSI-X the VMM implements emulation of > the standard MSI/MSI-X programming and swaps the fake addr/data pair > for a real one obtained from the hypervisor IRQ domain. > > To "deal" with this issue the SIOV spec suggests to add a per-device > PCI Capability that says "IMS works". Which means either: > - This is bare metal, so of course it works > - The VMM is trapping and emulating whatever the device specific IMS > programming is. > > The idea being that a VMM can never advertise the IMS cap flag to the > guest unles the VMM provides a device specific driver that does device > specific emulation to capture the addr/data pair. Remeber IMS doesn't > say how to program the addr/data pair! Every device is unique! > > On something like IDXD this emulation is not so hard, on something > like mlx5 this is completely unworkable. Further we never do > emulation on our devices, they always pass native hardware through, > even for SIOV-like cases. So is that true for interrupts too? Possibly you have the interrupt entries sitting in memory resident on the device? Don't we need the VMM to ensure they are brokered by VMM in either one of the two ways above? What if the guest creates some addr in the 0xfee... range how do we take care of interrupt remapping and such without any VMM assist? Its probably a gap in my understanding. > > In the end pci_subdevice_msi_create_irq_domain() is a platform > function. Either it should work completely on every device with no > device-specific emulation required in the VMM, or it should not work > at all and return -EOPNOTSUPP. > > The only sane way to implement this generically is for the VMM to > provide a hypercall to obtain a real *working* addr/data pair(s) and > then have the platform hand those out from > pci_subdevice_msi_create_irq_domain(). > > All IMS device drivers will work correctly. No VMM device emulation is > ever needed to translate addr/data pairs. > That's true. Probably this can work the same even for MSIx types too then? When we do interrupt remapping support in guest which would be required if we support x2apic in guest, I think this is something we should look into more carefully to make this work. One criteria that we generally tried to follow is driver that runs in host and guest are the same, and if needed they need some functionality make it work around some capability detection so the alternate path can be plummed in a generic way. I agree with the overall idea and we should certainly take that into consideration when we need IMS in guest support and in context of interrupt remapping. Hopefully I understood the overall concept. If I mis-understood any of this please let me know. Cheers, Ashok
