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