lkml.org 
[lkml]   [2022]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH v2 3/8] iommu/vt-d: Implement device_pasid domain attach ops
Date
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Thursday, March 17, 2022 8:04 AM
>
> On Wed, Mar 16, 2022 at 10:23:26PM +0000, Luck, Tony wrote:
>
> > Kernel users (ring0) can supply any PASID when they use
> > the ENQCMDS instruction. Is that what you mean when you
> > say "real applications"?
>
> I'm not talking about ENQCMD at all
>
> I'm saying I don't see much utility to have two PASIDs assigned to the
> same device that perform the same IOVA translation.
>
> So I would expect the list of attachments in an iommu_domain to have
> exactly one device in it and multiple PASIDs to the same device from
> the same iommu_domain is a oddball corner case we don't need to
> optimize for, beyond being able to allow it to happen.
>

In theory we do have one example with SIOV.

Say two mdev's of a same parent device are assigned to a guest and
each mdev gets a unique PASID to tag the vRID requests.

Then the guest attaches both mdev's to a stage-1 IOVA domain via
vIOMMU, e.g. when it further assigns them to an user application.

In this case the host iommu_domain wrapping the stage-1 page
table is attached by two PASIDs of the same device.

However iirc there are other tricky issues blocking this usage (Jacob
may remember more detail here) and we didn't hear strong interest
from customer on it. So this is just FYI for theoretical possibility and
I'm fine with even disallowing it before those issues are resolved.

Thanks
Kevin

\
 
 \ /
  Last update: 2022-03-18 06:48    [W:0.132 / U:0.696 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site