From: Jason Gunthorpe <jgg@ziepe.ca>
To: Vasant Hegde <vasant.hegde@amd.com>
Cc: iommu@lists.linux.dev, joro@8bytes.org,
suravee.suthikulpanit@amd.com, wei.huang2@amd.com,
jsnitsel@redhat.com
Subject: Re: [PATCH RESEND 03/10] iommu/amd: Initial SVA support for AMD IOMMU
Date: Tue, 5 Sep 2023 09:26:54 -0300 [thread overview]
Message-ID: <ZPcejmNW153rcRFA@ziepe.ca> (raw)
In-Reply-To: <d64d8066-7cee-46c6-2403-76eaa969fe53@amd.com>
On Tue, Sep 05, 2023 at 11:48:31AM +0530, Vasant Hegde wrote:
> Reading through the discussion so far again and the other series, my
> understanding is :
> - set_dev_pasid() will check the compatibility and bind device/pasid only if
> its compatibility. In AMD case we will check against protection domain. Ex:
> If we have two devices (devA and devB) in two different protection domain then:
> set_dev_pasid(sva_domain, devA, pasidX) - SUCCESS
> set_dev_pasid(sva_domain, devB, pasidX) - Compatibility check fail
> Core will allocate new SVA domain (sva_domain_new)
> set_dev_pasid(sva_domain_new, devB, pasidX) - SUCCESS
I don't expect a compatability check to ever fail on an AMD driver -
what condition do you imagine where re-allocating a SVA domain will
make it work with a device?
> - We will track mmu notifier and other data required for invalidation in SVA
> protection domain.
Yes
> - During invalidation, we will retrieve SVA protection domain using mmu
> notifier. Use device protection domain which was tracked in this SVA domain for
> invalidation.
The iommu_domain/protection_domain must NOT be 1:1 with a device. The
driver must maintain a list of devices attached to the domain, and the
per-device-attachment parameters like PASID/cache tags/etc.
This is very important.
> > It is not the same, you have this weird sva_pasid thing in here. PASID
> > is NOT part of the SVA layer.
> >
> > The API expects UNMANAGED domains will support PASID attach as well,
> > that is a significant use case.
>
> Can you elaborate the use cases you are referring here?
>
> We do have use cases for PASID and PASID+PRI. But I am not aware of any use case
> for UNMANAGED domain.
The iommu API is evolving so there are only a few domain types:
BLOCKED, IDENTITY, PAGING, SVA, OPAQUE
PAGING is what we today call UNMANAGED/DMA/DMA_FQ
PAGING domains need to support PASID+PRI, in today's language that
means UNMANAGED domains.
We have many use cases for PRI support with generic PAGING domains.
SVA is a special case of a PAGING domain where there is no map/unmap/invalidate
API and the IO page table comes from a mm_struct.
Start by making UNMANAGED (aka PAGING) domains work with PASID + PRI
and then SVA is a very small incremental step.
Jason
next prev parent reply other threads:[~2023-09-05 12:26 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-23 14:04 [PATCH RESEND 00/10] iommu/amd: SVA Support (Part 4) - SVA and IOPF Vasant Hegde
2023-08-23 14:04 ` [PATCH RESEND 01/10] iommu/amd: Rename amd_iommu_v2_supported() as amd_iommu_sva_supported() Vasant Hegde
2023-08-23 14:04 ` [PATCH RESEND 02/10] iommu/amd: Add support for enabling/disabling IOMMU features Vasant Hegde
2023-08-23 14:04 ` [PATCH RESEND 03/10] iommu/amd: Initial SVA support for AMD IOMMU Vasant Hegde
2023-08-23 14:28 ` Jason Gunthorpe
2023-08-28 10:39 ` Vasant Hegde
2023-08-30 17:07 ` Jason Gunthorpe
2023-09-05 6:18 ` Vasant Hegde
2023-09-05 12:26 ` Jason Gunthorpe [this message]
2023-09-05 14:39 ` Vasant Hegde
2023-09-05 18:14 ` Jason Gunthorpe
2023-09-11 12:16 ` Vasant Hegde
2023-09-11 12:41 ` Jason Gunthorpe
2023-08-23 14:04 ` [PATCH RESEND 04/10] iommu/amd: Add support to enable/disable SVA feature Vasant Hegde
2023-08-23 15:28 ` Jason Gunthorpe
2023-08-28 10:45 ` Vasant Hegde
2023-08-30 17:09 ` Jason Gunthorpe
2023-08-30 19:00 ` Vasant Hegde
2023-08-30 23:46 ` Jason Gunthorpe
2023-09-07 7:15 ` Vasant Hegde
2023-09-07 12:04 ` Jason Gunthorpe
2023-08-23 14:04 ` [PATCH RESEND 05/10] iommu/amd: Move PPR-related functions into ppr.c Vasant Hegde
2023-08-23 14:04 ` [PATCH RESEND 06/10] iommu/amd: Define per-IOMMU iopf_queue Vasant Hegde
2023-08-23 14:04 ` [PATCH RESEND 07/10] iommu/amd: Add support for page response Vasant Hegde
2023-08-23 14:04 ` [PATCH RESEND 08/10] iommu/amd: Add support for add/remove device for IOPF Vasant Hegde
2023-08-23 15:33 ` Jason Gunthorpe
2023-08-30 14:34 ` Vasant Hegde
2023-08-23 14:04 ` [PATCH RESEND 09/10] iommu/amd: Add IO page fault notifier handler Vasant Hegde
2023-08-23 14:04 ` [PATCH RESEND 10/10] iommu/amd: Introduce logic to enable/disable IOPF Vasant Hegde
2023-08-23 15:36 ` Jason Gunthorpe
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=ZPcejmNW153rcRFA@ziepe.ca \
--to=jgg@ziepe.ca \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=jsnitsel@redhat.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=vasant.hegde@amd.com \
--cc=wei.huang2@amd.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.