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 v5 14/17] iommu/amd: Refactor GCR3 table helper functions
Date: Wed, 24 Jan 2024 21:46:05 -0400 [thread overview]
Message-ID: <20240125014605.GV50608@ziepe.ca> (raw)
In-Reply-To: <c60ed34e-063a-b9fb-9255-365d3662f076@amd.com>
On Tue, Jan 23, 2024 at 02:24:51PM +0530, Vasant Hegde wrote:
> domain_id_is_per_dev() decides how to allocate domain ID. Right now for V2 and
> pass through mode we allocate per-device-domain-ID as they can switch to SVA.
That makes no sense. You don't need a domain id for passthrough mode
unless you are also installing a gcr3 table. You don't need to install
a gcr3 table unless there is a PASID being attached too.
Pre-setting the domain ID to avoid setting it when the GCR3 is later
loaded is spaghetti logic.
> > All this logic should be shared between the pasid and rid attach
> > paths.>
> > The passthrough thing is only an issue of DTE construction.
> >
> > If you build a DTE with a GCR3 table and RID=IDENTITY then you set
> > some bits, and that is it. Detect that case directly when you build
> > the DTE. It should have no effect on what domain ID is used to tag
> > translations retrived from a GCR3 table.
>
> We build DTE as soon as we attach device to domain.
>
> Now moving domain ID allocation to setup_gcr3_table complicates things.
> - In attach_device() path we want to allocate domain ID but not GCR3 table
> We can allocate GCR3 table, but if we don't use it its waste of memory.
It is a waste to allocate the domain id for identity too.
> - In SVA enablement path we want to allocate GCR3 table
> But by then domain ID should have been allocated. We don't want to allocate
> another domain_ID and change ID in SVA enablement path as our domain ID is not
> specific to GCR3.
Again, this seems to be a complication that is being created by the
DTE construction. You shouldn't need the caller to carefully sequence
what it is doing. The DTE programming should just install the correct
DTE for the *current state*.
A RID only identity/passthrough DTE does not have a GCR3 table and
does not need a unique domain ID.
> >> We need to handle passthrough as well. It doesn't make sense to allocate and
> >> keep GCR3 table when we are not going to use it.
> >
> > Then don't, and my diff didn't - but check for the passthrough case
> > directly against the attached domain as identity.
>
> We don't want to add condition check that depends on code path:
> like attach_device : allocate domain ID but not GCR3
> SVA path : Allocate GCR3 but not domain ID.
I'm not saying you should do that, I'm actively saying you should not
do that! All paths should be symmetric.
This matters, if you hope to implement the full driver functionality
the DTE construction must be clean, thare are too many cases
otherwise..
Jason
next prev parent reply other threads:[~2024-01-25 1:46 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-16 16:53 [PATCH v5 00/17] iommu/amd: SVA Support (part 3) - refactor support for GCR3 table Vasant Hegde
2024-01-16 16:53 ` [PATCH v5 01/17] iommu/amd: Pass struct iommu_dev_data to set_dte_entry() Vasant Hegde
2024-01-16 16:53 ` [PATCH v5 02/17] iommu/amd: Enable Guest Translation before registering devices Vasant Hegde
2024-01-16 16:53 ` [PATCH v5 03/17] iommu/amd: Introduce get_amd_iommu_from_dev() Vasant Hegde
2024-01-19 19:00 ` Jason Gunthorpe
2024-01-16 16:53 ` [PATCH v5 04/17] iommu/amd: Introduce struct protection_domain.pd_mode Vasant Hegde
2024-01-16 16:53 ` [PATCH v5 05/17] iommu/amd: Introduce per-device GCR3 table Vasant Hegde
2024-01-19 19:03 ` Jason Gunthorpe
2024-01-16 16:53 ` [PATCH v5 06/17] iommu/amd: Use protection_domain.flags to check page table mode Vasant Hegde
2024-01-16 16:53 ` [PATCH v5 07/17] iommu/amd: Introduce per-device domain ID to workaround potential TLB aliasing issue Vasant Hegde
2024-01-16 16:53 ` [PATCH v5 08/17] iommu/amd: Add support for device based TLB invalidation Vasant Hegde
2024-01-16 16:53 ` [PATCH v5 09/17] iommu/amd: Rearrange GCR3 table setup code Vasant Hegde
2024-01-16 16:53 ` [PATCH v5 10/17] iommu: Introduce iommu_group_mutex_assert() Vasant Hegde
2024-01-19 19:09 ` Jason Gunthorpe
2024-01-22 6:24 ` Vasant Hegde
2024-01-22 18:00 ` Jason Gunthorpe
2024-01-23 5:27 ` Vasant Hegde
2024-01-16 16:53 ` [PATCH v5 11/17] iommu/amd: Refactor helper function for setting / clearing GCR3 Vasant Hegde
2024-01-16 16:53 ` [PATCH v5 12/17] iommu/amd: Refactor attaching / detaching device functions Vasant Hegde
2024-01-16 16:53 ` [PATCH v5 13/17] iommu/amd: Refactor protection_domain helper functions Vasant Hegde
2024-01-16 16:53 ` [PATCH v5 14/17] iommu/amd: Refactor GCR3 table " Vasant Hegde
2024-01-19 19:59 ` Jason Gunthorpe
2024-01-22 10:23 ` Vasant Hegde
2024-01-22 18:26 ` Jason Gunthorpe
2024-01-23 8:54 ` Vasant Hegde
2024-01-25 1:46 ` Jason Gunthorpe [this message]
2024-01-25 12:11 ` Vasant Hegde
2024-01-25 15:53 ` Jason Gunthorpe
2024-01-16 16:53 ` [PATCH v5 15/17] iommu/amd: Remove unused flush pasid functions Vasant Hegde
2024-01-16 16:53 ` [PATCH v5 16/17] iommu/amd: Rearrange device flush code Vasant Hegde
2024-01-16 16:53 ` [PATCH v5 17/17] iommu/amd: Remove unused GCR3 table parameters from struct protection_domain Vasant Hegde
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=20240125014605.GV50608@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox