Re: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection

From: Jason Gunthorpe
Date: Mon Nov 09 2020 - 11:46:23 EST


On Mon, Nov 09, 2020 at 07:37:03AM +0000, Tian, Kevin wrote:
> > 3) SIOV sub device assigned to the guest.
> >
> > The difference between SIOV and SRIOV is the device must attach a
> > PASID to every TLP triggered by the guest. Logically we'd expect
> > when IMS is used in this situation the interrupt MemWr is tagged
> > with bus/device/function/PASID to uniquly ID the guest and the same
> > security protection scheme from #2 applies.
>
> Unfortunately no. Intel VT-d only treats MemWr w/o PASID to 0xFEExxxxx
> as interrupt request. MemWr w/ PASID, even to 0xFEE, is translated
> normally through DMA remapping page table.

I've heard that current IOMMUs are limited as well, but IMHO, as I
describe, if you want full symmetry then you want to route interrupts
via PASID for SIOV. Otherwise the architecture is incomplete.

At least from a Linux and VMM perspective this should be planned
for. It is the only generic way to have a sub device assigned to a
guest and still have access to IMS.

> Does your device already implement such capability? We can bring this
> request back to the hardware team.

In some cases we can generate PASID tagged TLPs for interrupt
messages, if there was a reason to do that.

> Yes, this is the main worry here. While all agree that using hypercall is
> the proper way to virtualize IMS, how to disable it when hypercall is
> not available is a more urgent demand at current stage.

Hopefully Thomas's note about checking for virtualization will help..

> btw in reality such ACPI extension doesn't exist yet, which likely will
> take some time. In the meantime we already have pending usages
> like IDXD. Do you suggest holding these patches until we get ASWG
> to accept the extension, or accept using Intel IMS cap as a vendor
> specific mitigation to move forward while the platform flag is being
> worked on? Anyway the IMS cap is already defined and can help fix
> some broken cases.

I think you need to sort something generic out, these half baked
architectures just make it some other teams problem.

Thomas's suggestion to check cpuid seems reasonably workable

Jason