All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Yi Liu <yi.l.liu@intel.com>
Cc: joro@8bytes.org, kevin.tian@intel.com, baolu.lu@linux.intel.com,
	alex.williamson@redhat.com, eric.auger@redhat.com,
	nicolinc@nvidia.com, kvm@vger.kernel.org,
	chao.p.peng@linux.intel.com, iommu@lists.linux.dev,
	zhenzhong.duan@intel.com, vasant.hegde@amd.com
Subject: Re: [PATCH v5 08/12] iommufd: Enforce pasid compatible domain for PASID-capable device
Date: Fri, 6 Dec 2024 13:58:04 -0400	[thread overview]
Message-ID: <20241206175804.GQ1253388@nvidia.com> (raw)
In-Reply-To: <39a68273-fd4b-4586-8b4a-27c2e3c8e106@intel.com>

On Fri, Dec 06, 2024 at 03:57:39PM +0800, Yi Liu wrote:
> Hi Jason, Vasant,
> 
> When cooking new version, I got three opens on enforcing using
> pasid-compatible domains to pasid-capable device in iommufd as suggested
> in [1].
> 
> - Concept problem when considering nested domain
>   IIUC. pasid-compatible domain means the domain can be attached to PASID.
>   e.g. AMD requires using V2 page table hence it can be configed to GCR3.
>   However, the nested domain uses both V1 and V2 page table, I don't think
>   it can be attached to PASID on AMD. So nested domain can not be
>   considered as pasid-compatible. 

Yes.

>   Based on this, this enforcement only
>   applies to paging-domains. If so, do we still need to enforce it in
>   iommufd? Will it simpler to let the AMD iommu driver to deal it?

I think driver should deal with it, Intel doesn't have that
limitation. I sent patches to fix that detection for AMD and ARM
already.

> - PASID-capable device v.s. PASID-enabled device
>   We keep saying PASID-capable, but system may not enable it. Would it
>   better enforce the pasid-compatible domain for PASID-enabled device?
>   Seems all iommu vendor will enable PASID if it's supported. But
>   conceptly, it is be more accurate if only do it when PASID is
>   enabled.

If we want to do more here we should put the core code in charge of
deciding of a device will be PASID enabled and the IOMMU driver only
indicates if it can be PASID supported.

>   For PCI devices, we can check if the pasid cap is enabled from device
>   config space. But for non-PCI PASID support (e.g. some ARM platform), I
>   don't know if there is any way to check the PASID enabled or not. Or, to
>   cover both, we need an iommu API to check PASID enabled or not?

Yes, some iommu API, I suggest a flag in the common iommu_device. We
already have max_pasids there, it may already be nearly enough.
 
> - Nest parent domain should never be pasid-compatible?

Up to the driver.

>   I think the AMD iommu uses the V1 page table format for the parent
>   domain. Hence parent domain should not be allocated with the
>   IOMMU_HWPT_ALLOC_PASID flag. Otherwise, it does not work. Should this
>   be enforced in iommufd?

Enforced in the driver.

iommufd should enforce that the domain was created with
IOMMU_HWPT_ALLOC_PASID before passing the HWPT to any pasid
attach/replace function.

Jason

  reply	other threads:[~2024-12-06 17:58 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-04 13:25 [PATCH v5 00/12] iommufd support pasid attach/replace Yi Liu
2024-11-04 13:25 ` [PATCH v5 01/12] iommu: Introduce a replace API for device pasid Yi Liu
2024-11-05  3:58   ` Baolu Lu
2024-11-05  7:49     ` Yi Liu
2024-11-05  7:57       ` Baolu Lu
2024-11-05  8:10         ` Yi Liu
2024-11-05  8:14           ` Baolu Lu
2024-11-05 15:10           ` Jason Gunthorpe
2024-11-06  8:52             ` Baolu Lu
2024-11-04 13:25 ` [PATCH v5 02/12] iommufd: Refactor __fault_domain_replace_dev() to be a wrapper of iommu_replace_group_handle() Yi Liu
2024-11-05  5:06   ` Baolu Lu
2024-11-05  8:01     ` Yi Liu
2024-11-05  8:03       ` Baolu Lu
2024-11-05  8:12         ` Yi Liu
2024-11-04 13:25 ` [PATCH v5 03/12] iommufd: Move the iommufd_handle helpers to device.c Yi Liu
2024-11-05  5:21   ` Baolu Lu
2024-11-05  8:01     ` Yi Liu
2024-11-05 15:18       ` Jason Gunthorpe
2024-11-04 13:25 ` [PATCH v5 04/12] iommufd: Always pass iommu_attach_handle to iommu core Yi Liu
2024-11-04 13:25 ` [PATCH v5 05/12] iommufd: Pass pasid through the device attach/replace path Yi Liu
2024-11-04 13:25 ` [PATCH v5 06/12] iommufd: Support pasid attach/replace Yi Liu
2024-11-04 13:25 ` [PATCH v5 07/12] iommufd: Allocate auto_domain with IOMMU_HWPT_ALLOC_PASID flag if device is PASID-capable Yi Liu
2024-11-04 13:25 ` [PATCH v5 08/12] iommufd: Enforce pasid compatible domain for PASID-capable device Yi Liu
2024-12-06  7:57   ` Yi Liu
2024-12-06 17:58     ` Jason Gunthorpe [this message]
2024-12-07 10:49       ` Yi Liu
2024-12-09 14:57         ` Jason Gunthorpe
2024-12-10  3:15           ` Yi Liu
2024-12-11  8:46             ` Tian, Kevin
2024-12-12  3:15               ` Yi Liu
2024-12-12  5:51                 ` Tian, Kevin
2024-12-12  7:13                   ` Yi Liu
2024-12-13  2:43                     ` Tian, Kevin
2024-12-13  7:19                       ` Yi Liu
2024-12-13  7:52                         ` Tian, Kevin
2024-12-13  8:11                           ` Yi Liu
2024-12-13  8:12                             ` Yi Liu
2024-12-13 12:40                           ` Jason Gunthorpe
2024-12-14  9:04                             ` Yi Liu
2024-12-16  8:26                               ` Tian, Kevin
2024-12-17 13:28                                 ` Yi Liu
2024-12-11 18:06             ` Jason Gunthorpe
2024-11-04 13:25 ` [PATCH v5 09/12] iommufd/selftest: Add set_dev_pasid in mock iommu Yi Liu
2024-11-04 13:25 ` [PATCH v5 10/12] iommufd/selftest: Add a helper to get test device Yi Liu
2024-11-04 13:25 ` [PATCH v5 11/12] iommufd/selftest: Add test ops to test pasid attach/detach Yi Liu
2024-11-04 13:25 ` [PATCH v5 12/12] iommufd/selftest: Add coverage for iommufd " Yi Liu
2024-11-13  1:37 ` [PATCH v5 00/12] iommufd support pasid attach/replace Jason Gunthorpe
2024-11-13  3:01   ` Baolu Lu
2024-11-13  3:24     ` Yi Liu
2024-11-13  3:26       ` Yi Liu
2024-11-15  9:24         ` Yi Liu

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=20241206175804.GQ1253388@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=eric.auger@redhat.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=vasant.hegde@amd.com \
    --cc=yi.l.liu@intel.com \
    --cc=zhenzhong.duan@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.