lkml.org 
[lkml]   [2022]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [RFC v16 1/9] iommu: Introduce attach/detach_pasid_table API
Date
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Friday, December 17, 2021 4:49 AM
>
> On Sat, Dec 11, 2021 at 03:57:45AM +0000, Tian, Kevin wrote:
>
> > This might be the only open as I still didn't see why we need an
> > explicit flag to claim a 'full device' thing. From kernel p.o.v the
> > ARM case is no different from Intel that both allows an user
> > page table attached to vRID, just with different format and
> > addr width (Intel is 64bit, ARM is 84bit where PASID can be
> > considered a sub-handle in the 84bit address space and not
> > the kernel's business).
>
> I think the difference is intention.
>
> In one case the kernel is saying 'attach a RID and I intend to use
> PASID' in which case the kernel user can call the PASID APIs.
>
> The second case is saying 'I will not use PASID'.
>
> They are different things and I think it is a surprising API if the
> kernel user attaches a domain, intends to use PASID and then finds out
> it can't, eg because an ARM user page table was hooked up.
>
> If you imagine the flag as 'I intend to use PASID' I think it makes a
> fair amount of sense from an API design too.
>
> We could probably do without it, at least for VFIO and qemu cases, but
> it seems a little bit peculiar to me.
>

ok, combining the kernel user makes the flag more sensible.

Thanks
Kevin

\
 
 \ /
  Last update: 2022-01-04 03:43    [W:0.074 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site