RE: [RFC v2] /dev/iommu uAPI proposal
From: "Tian, Kevin" <kevin.tian@intel.com>
Date: 2021-08-05 22:44:26
Also in:
linux-iommu, lkml
From: Jason Gunthorpe <jgg@nvidia.com> Sent: Thursday, August 5, 2021 7:27 PM On Wed, Aug 04, 2021 at 10:59:21PM +0000, Tian, Kevin wrote:quoted
quoted
From: Jason Gunthorpe <jgg@nvidia.com> Sent: Wednesday, August 4, 2021 10:05 PM On Mon, Aug 02, 2021 at 02:49:44AM +0000, Tian, Kevin wrote:quoted
Can you elaborate? IMO the user only cares about the label (devicecookiequoted
quoted
quoted
plus optional vPASID) which is generated by itself when doing theattachingquoted
quoted
quoted
call, and expects this virtual label being used in various spots(invalidation,quoted
quoted
quoted
page fault, etc.). How the system labels the traffic (the physical RID orRID+quoted
quoted
quoted
PASID) should be completely invisible to userspace.I don't think that is true if the vIOMMU driver is also emulating PASID. Presumably the same is true for other PASID-like schemes.I'm getting even more confused with this comment. Isn't it the consensus from day one that physical PASID should not be exposed to userspace as doing so breaks live migration?Uh, no?quoted
with PASID emulation vIOMMU only cares about vPASID instead of pPASID, and the uAPI only requires user to register vPASID instead of reporting pPASID back to userspace...vPASID is only a feature of one device in existance, so we can't make vPASID mandatory.
sure. my point is just that if vPASID is being emulated there is no need of exposing pPASID to user space. Can you give a concrete example where pPASID must be exposed and how the user wants to use this information? Thanks Kevin