On Mon, Nov 09, 2020 at 09:14:12PM -0800, Raj, Ashok wrote: > There are multiple tools (such as logic analyzers) and OEM test validation > harnesses that depend on such DWORD sized DMA writes with no PASID as > interrupt > messages. One of the feedback we had received in the development of the > specification was to avoid impacting such tools irrespective of > MSI-X or IMS
This is a really bad reason to make a poor decision for system security. Relying on trapping/emulation increases the attack surface and complexity of the VMM and the device which now have to create this artificial split, which does not exist in SRIOV. Hopefully we won't see devices get this wrong, but any path that allows the guest to cause the device to create TLPs outside its IOMMU containment is security worrysome. > was used for interrupt message storage (on the wire they follow the > same format), and also to ensure interoperability of devices > supporting IMS across CPU vendors (who may not support PASID TLP > prefix). This is one reason that led to interrupts from IMS to not > use PASID (and match the wire format of MSI/MSI-X generated > interrupts). The other problem was disambiguation between DMA to > SVM v/s interrupts. This is a defect in the IOMMU, not something fundamental. The IOMMU needs to know if the interrupt range is active or not for each PASID. Process based SVA will, of course, not enable interrupts on the PASID, VM Guest based PASID will. > Intel had published the specification almost 2 years back and have > comprehended all the feedback received from the ecosystem > (both open-source and others), along with offering the specification > to be implemented by any vendors (both device and CPU vendors). > There are few device vendors who are implementing to the spec already and > are being explored for support by other CPU vendors Which is why it is such a shame that including PASID in the MSI was deliberately skipped in the document, the ecosystem could have been much aligned to this solution by now :( Jason
