From: Jason Gunthorpe <jgg@nvidia.com>
To: "Suthikulpanit, Suravee" <suravee.suthikulpanit@amd.com>
Cc: linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
joro@8bytes.org, robin.murphy@arm.com, vasant.hegde@amd.com,
kevin.tian@intel.com, jon.grimm@amd.com, santosh.shukla@amd.com,
pandoh@google.com, kumaranand@google.com
Subject: Re: [PATCH v6 0/9] iommu/amd: Use 128-bit cmpxchg operation to update DTE
Date: Thu, 31 Oct 2024 08:33:55 -0300 [thread overview]
Message-ID: <20241031113355.GC10193@nvidia.com> (raw)
In-Reply-To: <e617c4ae-c5fb-444a-9649-ffc7d41f79ba@amd.com>
On Thu, Oct 31, 2024 at 04:15:02PM +0700, Suthikulpanit, Suravee wrote:
> On 10/16/2024 9:22 PM, Jason Gunthorpe wrote:
> >
> > ....
> >
> > I wanted to see how far this was to being split up neatly like ARM is,
> > I came up with this, which seems pretty good to me. This would
> > probably be the next step to get to, then you'd lift the individual
> > set functions higher up the call chain into their respective attach
> > functions.
>
> I like this idea and will look into adopting this code when I submit the
> nested translation stuff (right after this series) since it will affect the
> set_dte_entry().
Yes, I definitely want to see this kind of code structure before
nested translation.
> > static void set_dte_entry(struct amd_iommu *iommu,
> > struct iommu_dev_data *dev_data)
> > {
> > u32 old_domid;
> > struct dev_table_entry new = {};
> > struct protection_domain *domain = dev_data->domain;
> > struct gcr3_tbl_info *gcr3_info = &dev_data->gcr3_info;
> > struct dev_table_entry *dte = &get_dev_table(iommu)[dev_data->devid];
> >
> > make_clear_dte(dev_data, dte, &new);
> > if (gcr3_info && gcr3_info->gcr3_tbl)
> > set_dte_gcr3_table(iommu, dev_data, &new);
> > else if (domain->iop.mode == PAGE_MODE_NONE)
> > set_dte_identity(iommu, dev_data, &new);
> > else
> > set_dte_paging(iommu, dev_data, &new);
>
> This will need to be change once we add nested translation support because
> we need to call both set_dte_paging() and set_dte_gcr3().
The idea would be to remove set_dte_entry() because the attach
functions just call their specific set_dte_xx() directly, like how arm
is structured.
That will make everything much clearer.
Then the nested attach function would call some set_dte_nested() and
it would use set_dte_paging() internally.
Getting to this level is necessary to get the hitless replace, which
is important..
I hope this series gets landed this cycle, next cycle you should try
to get to hitless replace on the domain path, including this stuff,
then adding the nested domain should be straightforward!
Jason
prev parent reply other threads:[~2024-10-31 11:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-16 5:17 [PATCH v6 0/9] iommu/amd: Use 128-bit cmpxchg operation to update DTE Suravee Suthikulpanit
2024-10-16 5:17 ` [PATCH v6 1/9] iommu/amd: Disable AMD IOMMU if CMPXCHG16B feature is not supported Suravee Suthikulpanit
2024-10-16 5:17 ` [PATCH v6 2/9] asm/rwonce: Introduce [READ|WRITE]_ONCE() support for __int128 Suravee Suthikulpanit
2024-10-16 13:08 ` Jason Gunthorpe
2024-10-16 5:17 ` [PATCH v6 3/9] iommu/amd: Introduce helper function to update 256-bit DTE Suravee Suthikulpanit
2024-10-16 5:17 ` [PATCH v6 4/9] iommu/amd: Introduce per-device DTE cache to store persistent bits Suravee Suthikulpanit
2024-10-16 13:21 ` Jason Gunthorpe
2024-10-16 5:17 ` [PATCH v6 5/9] iommu/amd: Modify set_dte_entry() to use 256-bit DTE helpers Suravee Suthikulpanit
2024-10-16 13:52 ` Jason Gunthorpe
2024-10-16 14:07 ` Jason Gunthorpe
2024-10-16 14:12 ` Jason Gunthorpe
2024-10-16 5:17 ` [PATCH v6 6/9] iommu/amd: Introduce helper function get_dte256() Suravee Suthikulpanit
2024-10-16 5:17 ` [PATCH v6 7/9] iommu/amd: Move erratum 63 logic to write_dte_lower128() Suravee Suthikulpanit
2024-10-16 13:30 ` Jason Gunthorpe
2024-10-31 8:53 ` Suthikulpanit, Suravee
2024-10-31 8:53 ` Suthikulpanit, Suravee
2024-10-16 5:17 ` [PATCH v6 8/9] iommu/amd: Modify clear_dte_entry() to avoid in-place update Suravee Suthikulpanit
2024-10-16 5:17 ` [PATCH v6 9/9] iommu/amd: Lock DTE before updating the entry with WRITE_ONCE() Suravee Suthikulpanit
2024-10-16 14:22 ` [PATCH v6 0/9] iommu/amd: Use 128-bit cmpxchg operation to update DTE Jason Gunthorpe
2024-10-31 9:15 ` Suthikulpanit, Suravee
2024-10-31 11:33 ` Jason Gunthorpe [this message]
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=20241031113355.GC10193@nvidia.com \
--to=jgg@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jon.grimm@amd.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kumaranand@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pandoh@google.com \
--cc=robin.murphy@arm.com \
--cc=santosh.shukla@amd.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=vasant.hegde@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