From: Nicolin Chen <nicolinc@nvidia.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "jgg@nvidia.com" <jgg@nvidia.com>,
"corbet@lwn.net" <corbet@lwn.net>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"eric.auger@redhat.com" <eric.auger@redhat.com>,
"shameerali.kolothum.thodi@huawei.com"
<shameerali.kolothum.thodi@huawei.com>,
"smostafa@google.com" <smostafa@google.com>,
"baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>
Subject: Re: [PATCH] Documentation: userspace-api: iommufd: Update HWPT_PAGING and HWPT_NESTED
Date: Wed, 11 Sep 2024 00:30:32 -0700 [thread overview]
Message-ID: <ZuFHGHd2S+r6XzyN@nvidia.com> (raw)
In-Reply-To: <BN9PR11MB5276142EF52299176BA3179F8C9B2@BN9PR11MB5276.namprd11.prod.outlook.com>
On Wed, Sep 11, 2024 at 07:09:15AM +0000, Tian, Kevin wrote:
> > From: Nicolin Chen <nicolinc@nvidia.com>
> > Sent: Wednesday, September 11, 2024 4:41 AM
> >
> > + feature flag. This can be either an UNMANAGED stage-1 domain for a
> > device
> > + running in the user space, or a nesting parent stage-2 domain for
> > mappings
> > + from guest-level physical addresses to host-level physical addresses.
>
> the former part is inaccurate. It could be an UNMANAGED stage-2 domain.
>
> > +
> > +- IOMMUFD_OBJ_HWPT_NESTED, representing an actual hardware I/O
> > page table
> > + (i.e. a single struct iommu_domain) managed by user space (e.g. guest OS).
> > + "NESTED" indicates that this type of HWPT can be linked to an
> > HWPT_PAGING.
>
> s/can be/should be/
Was thinking of the 2nd choice: HWPT_NESTED->vIOMMU (HWPT_PAGING)
Yet, I think "should" could fit that narrative too. Will change.
> >
> > -3. IOMMUFD_OBJ_HW_PAGETABLE is created when an external driver calls
> > the IOMMUFD
> > +3. IOMMUFD_OBJ_HWPT_PAGING can be created in two ways:
> > +
> > + IOMMUFD_OBJ_HWPT_PAGING is created when an external driver calls
> > the IOMMUFD
> > kAPI to attach a bound device to an IOAS. Similarly the external driver uAPI
> > allows userspace to initiate the attaching operation. If a compatible
> > pagetable already exists then it is reused for the attachment. Otherwise a
> > new pagetable object and iommu_domain is created. Successful
> > completion of
> > this operation sets up the linkages among IOAS, device and
> > iommu_domain. Once
> > - this completes the device could do DMA.
> > -
> > - Every iommu_domain inside the IOAS is also represented to userspace as
> > a
> > - HW_PAGETABLE object.
> > + this completes the device could do DMA. Note that every iommu_domain
> > inside
> > + the IOAS is also represented to userspace as an
> > IOMMUFD_OBJ_HWPT_PAGING.
>
> the last sentence is redundant. here we are talking about how HWPT_PAGING
> is created so it's implied. probably you can state that HWPT_PAGING object
> is created when talking about "otherwise a new page table object and
> iommu_domain is created".
I don't quite get this part...where is the redundancy? And where
is "otherwise a new page table object .."?
> > +
> > +4. IOMMUFD_OBJ_HWPT_NESTED can be only manually created via the
> > IOMMU_HWPT_ALLOC
> > + uAPI, provided an hwpt_id via @pt_id to associate the new
> > HWPT_NESTED object
> > + to the corresponding HWPT_PAGING object. The associating
> > HWPT_PAGING object
> > + must be a nesting parent manually allocated via the same uAPI previously
> > with
> > + an IOMMU_HWPT_ALLOC_NEST_PARENT flag, otherwise the allocation
> > will fail. The
> > + allocation will be further validated by the IOMMU driver of an IOMMU
> > hardware
> > + that the given device (via @dev_id) is physically linked to, to ensure that
> > + the nesting parent domain and a nested domain being allocated are
> > compatible.
>
> just "validated by the IOMMU driver to ensure that ..."
OK.
> >
> > .. note::
> >
> > - Future IOMMUFD updates will provide an API to create and manipulate
> > the
> > - HW_PAGETABLE directly.
> > + Either a manual IOMMUFD_OBJ_HWPT_PAGING or an
> > IOMMUFD_OBJ_HWPT_NESTED is
> > + created via the same IOMMU_HWPT_ALLOC uAPI. The difference is at
> > the type
> > + of the object passed in via the @pt_id field of struct
> > iommufd_hwpt_alloc:
> > + When @pt_id carries an ioas_id to an IOAS object, the
> > IOMMU_HWPT_ALLOC
> > + call is instructed to allocate an HWPT_PAGING object only.
> > + When @pt_id carries an hwpt_id to an HWPT_PAGING object, the uAPI
> > call
> > + is instructed to allocate an HWPT_NESTED object only.
> > + If any other type of object is passed in via the @pt_id, the uAPI call
> > + will fail.
> >
>
> I'm not sure whether this note is still required. probably just one
> sentence to highlight that it's @pt_id field to mark out the
> object type? most descriptions duplicate with the earlier words.
I feel it's a nice summary though... I'll see how I can simplify it.
Thanks
Nicolin
next prev parent reply other threads:[~2024-09-11 7:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-10 20:41 [PATCH] Documentation: userspace-api: iommufd: Update HWPT_PAGING and HWPT_NESTED Nicolin Chen
2024-09-11 2:13 ` Bagas Sanjaya
2024-09-11 4:24 ` Nicolin Chen
2024-09-11 7:28 ` Bagas Sanjaya
2024-09-11 7:09 ` Tian, Kevin
2024-09-11 7:30 ` Nicolin Chen [this message]
2024-09-11 8:06 ` Tian, Kevin
2024-09-11 19:52 ` Nicolin Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZuFHGHd2S+r6XzyN@nvidia.com \
--to=nicolinc@nvidia.com \
--cc=baolu.lu@linux.intel.com \
--cc=corbet@lwn.net \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=smostafa@google.com \
--cc=yi.l.liu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).