On Tue, Jun 08, 2021 at 08:57:35AM -0700, Dave Jiang wrote: > In order to ensure unprivileged software doesn’t use a handle that > doesn’t belong to it, DSA provides a facility for system software to > associate a PASID with an interrupt handle, and DSA will ensure the > entity submitting the work is authorized to generate interrupt via > this interrupt handle (PASID stored in IMS array should match PASID > in descriptor). How does a SVA userspace allocate interrupt handles and make them affine to the proper CPU(s)? IIRC interrupts are quite limited per-CPU due to the x86 IDT, generally I would expect a kernel driver to allocate at most one IRQ per CPU. However here you say each process using SVA needs a unique interrupt handle with its PASID encoded in it. Since the IMS irqchip you are using can't share IRQs between interrupt handles does this mean that every time userspace creates a SVA it triggers consumption of an IMS and IDT entry on some CPU? How is this secure against DOS of limited kernel resources? > driver does this by having the guest driver fill the virtual MSIX > permission table (device specific), which contains a PASID entry for > each of the MSIX vectors when SVA is turned on. The MMIO write to > the guest vMSIXPERM table allows the host driver MMIO emulation code > to retrieve the guest PASID and attempt to match that with the host > PASID. That host PASID is programmed to the IMS entry that is > backing the guest MSIX vector. This cannot be done via the common > path and therefore requires the auxdata helper function to program > the IMS PASID fields. So a VM guest gets a SW emulated vMSIXPERM table along side MSI-X, but the physical driver went down this IMS adventure? And you had to do this because, as discussed earlier, true IMS is not usable in the guest due to other platform problems? Jason
