lkml.org 
[lkml]   [2020]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection
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

\
 
 \ /
  Last update: 2020-11-09 17:47    [W:0.100 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site