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 v3 12/13] iommu/amd: Refactor GCR3 table helper functions
Date: Tue, 7 Nov 2023 09:31:57 -0400 [thread overview]
Message-ID: <20231107133157.GZ4634@ziepe.ca> (raw)
In-Reply-To: <d905c553-964a-b15e-19f5-1be4896a7818@amd.com>
On Tue, Nov 07, 2023 at 11:43:10AM +0530, Vasant Hegde wrote:
> > You should be moving to a direction where the ops->attach_dev does
> > exactly one update to the DTE. It loads the new correct value of the
> > DTE that attach_dev is asking to create. All this repeated touching of
> > the DTE during the attach_dev flow is sort of a functional bug, or at
> > least a sub-optimal implementation of the API.
>
> We are not touching DTE repeatedly. We do need to detach device (so touch DTE)
> and then attach device to domain (another touch).
Twice is repeatedly. Again look at how smmuv3 turned out, there is
exactly *ONE* DTE update per op callback.
> I am not confident to make change like above (i. e. just attaching device to new
> domain and then destroying old domain related data) in this series. Those
> improvements can be looked into it later.
Sure, but you need to start organizing the code to work like this with
the proper layers and division of work.
The best advice I can give you is to make it look more like SMMUv3
because that is the only example that solves *everything* If each
series moves things closer to that then you'll be in a better position
to fix everything eventually.
Jason
next prev parent reply other threads:[~2023-11-07 13:31 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-13 15:16 [PATCH v3 00/13] iommu/amd: SVA Support (part 3) - refactor support for GCR3 table Vasant Hegde
2023-10-13 15:16 ` [PATCH v3 01/13] iommu/amd: Pass struct iommu_dev_data to set_dte_entry() Vasant Hegde
2023-11-05 18:00 ` Jason Gunthorpe
2023-10-13 15:16 ` [PATCH v3 02/13] iommu/amd: Introduce get_amd_iommu_from_dev() Vasant Hegde
2023-11-05 18:05 ` Jason Gunthorpe
2023-11-06 11:54 ` Vasant Hegde
2023-10-13 15:16 ` [PATCH v3 03/13] iommu/amd: Introduce struct protection_domain.pd_mode Vasant Hegde
2023-11-05 18:07 ` Jason Gunthorpe
2023-10-13 15:16 ` [PATCH v3 04/13] iommu/amd: Introduce per-device GCR3 table Vasant Hegde
2023-10-13 15:16 ` [PATCH v3 05/13] iommu/amd: Use protection_domain.flags to check page table mode Vasant Hegde
2023-10-13 15:16 ` [PATCH v3 06/13] iommu/amd: Introduce per-device domain ID to workaround potential TLB aliasing issue Vasant Hegde
2023-11-05 18:16 ` Jason Gunthorpe
2023-11-06 12:39 ` Vasant Hegde
2023-11-06 13:36 ` Jason Gunthorpe
2023-11-07 5:30 ` Vasant Hegde
2023-11-07 13:21 ` Jason Gunthorpe
2023-12-12 5:53 ` Vasant Hegde
2023-10-13 15:16 ` [PATCH v3 07/13] iommu/amd: Add support for device based flush TLB Vasant Hegde
2023-10-13 15:16 ` [PATCH v3 08/13] iommu/amd: Rearrange GCR3 table setup code Vasant Hegde
2023-11-05 18:16 ` Jason Gunthorpe
2023-10-13 15:16 ` [PATCH v3 09/13] iommu/amd: Refactor helper function for setting / clearing GCR3 Vasant Hegde
2023-11-06 16:51 ` Jason Gunthorpe
2023-11-07 6:16 ` Vasant Hegde
2023-10-13 15:16 ` [PATCH v3 10/13] iommu/amd: Refactor helper function for attaching / detaching device Vasant Hegde
2023-11-06 17:29 ` Jason Gunthorpe
2023-11-07 5:55 ` Vasant Hegde
2023-11-07 13:28 ` Jason Gunthorpe
2023-11-23 17:39 ` Vasant Hegde
2023-11-30 17:55 ` Jason Gunthorpe
2023-12-12 5:41 ` Vasant Hegde
2023-12-12 14:59 ` Jason Gunthorpe
2023-12-18 5:17 ` Vasant Hegde
2023-10-13 15:16 ` [PATCH v3 11/13] iommu/amd: Refactor protection_domain helper functions Vasant Hegde
2023-11-06 17:30 ` Jason Gunthorpe
2023-10-13 15:16 ` [PATCH v3 12/13] iommu/amd: Refactor GCR3 table " Vasant Hegde
2023-11-06 17:40 ` Jason Gunthorpe
2023-11-07 6:13 ` Vasant Hegde
2023-11-07 13:31 ` Jason Gunthorpe [this message]
2023-11-23 17:23 ` Vasant Hegde
2023-11-23 17:24 ` Jason Gunthorpe
2023-10-13 15:16 ` [PATCH v3 13/13] iommu/amd: Remove unused GCR3 table parameters from struct protection_domain Vasant Hegde
2023-11-06 17:33 ` 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=20231107133157.GZ4634@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