Thread (268 messages) 268 messages, 15 authors, 2021-06-08

Re: [PATCH V4 05/18] iommu/ioasid: Redefine IOASID set and allocation APIs

From: Jason Gunthorpe <hidden>
Date: 2021-05-06 12:27:37
Also in: linux-iommu, lkml

On Thu, May 06, 2021 at 09:23:48AM +0200, Jean-Philippe Brucker wrote:
On Wed, May 05, 2021 at 01:04:46PM -0700, Jacob Pan wrote:
quoted
quoted
quoted
For ARM, since the guest owns the per device PASID table. There is no
need to allocate PASIDs from the host nor the hypervisor. Without SWQ,
there is no need for global PASID/SSID either. So PASID being global
for ARM is for simplicity in case of host PASID/SSID.  
It isn't clear how ARM can support PASID and mdev but that is an
unrelated issue..
AFAIK, the current SMMU device assignment is per RID, since only one stage2
page tables per RID, not per PASID. This is equivalent to the older VT-d
spec. prior to scalable mode.
Yes that's right. Since SMMUv3 has a single level-2 page table per RID, it
doesn't support assigning level-1 page tables to guests for mdevs (sub-VF
devices). So no PASIDs for mdevs, which also means each guest has its own
PASID space and the host doesn't track guest PASIDs.
Basically it means when the guest's top level IOASID is created for
nesting that IOASID claims all PASID's on the RID and excludes any
PASID IOASIDs from existing on the RID now or in future.

Which would be a different behavior than something like Intel's top
level IOASID that doesn't claim all the PASIDs.

Lots of little special flags in here :|

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help