On Sun, 2020-11-08 at 10:11 -0800, Raj, Ashok wrote: > 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. No, interrupt remapping is not required for X2APIC in guests They can have X2APIC and up to 32768 CPUs without needing interrupt remapping at all. Only if they want more than 32768 vCPUs, or to do nested virtualisation and actually remap for the benefit of *their* (L2+) guests would they need IR.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
