From: Jason Gunthorpe <jgg@nvidia.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Uros Bizjak <ubizjak@gmail.com>, Joerg Roedel <joro@8bytes.org>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
linux-kernel@vger.kernel.org, iommu@lists.linux.dev,
Robin Murphy <robin.murphy@arm.com>,
vasant.hegde@amd.com, Kevin Tian <kevin.tian@intel.com>,
jon.grimm@amd.com, santosh.shukla@amd.com, pandoh@google.com,
kumaranand@google.com, Linux-Arch <linux-arch@vger.kernel.org>
Subject: Re: [PATCH v9 03/10] asm/rwonce: Introduce [READ|WRITE]_ONCE() support for __int128
Date: Thu, 7 Nov 2024 09:37:25 -0400 [thread overview]
Message-ID: <20241107133725.GD520535@nvidia.com> (raw)
In-Reply-To: <4c9fd886-3305-4797-9091-3f9b0b9ee0b6@app.fastmail.com>
On Thu, Nov 07, 2024 at 11:01:58AM +0100, Arnd Bergmann wrote:
> >> and later:
> >>
> >> * Yes, this permits 64-bit accesses on 32-bit architectures. These will
> >> * actually be atomic in some cases (namely Armv7 + LPAE), but for others we
> >> * rely on the access being split into 2x32-bit accesses for a 32-bit quantity
> >> * (e.g. a virtual address) and a strong prevailing wind.
> >>
> >> This is the "strong prevailing wind", mentioned in the patch review at [1].
> >>
> >> [1] https://lore.kernel.org/lkml/20241016130819.GJ3559746@nvidia.com/
>
> I understand the special case for ARMv7VE. I think the more important
> comment in that file is
>
> * Use __READ_ONCE() instead of READ_ONCE() if you do not require any
> * atomicity. Note that this may result in tears!
That makes sense, let's just use that and there is no need to change
anything here?
Uros?
> >> FYI, Processors with AVX guarantee 128bit atomic access with SSE
> >> 128bit move instructions, see e.g. [2].
> >>
> >> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
>
> AVX instructions are not used in the kernel. If you want atomic
> loads, that has to rely on architecture specific instructions
> like cmpxchg16b on x86-64 or ldp on arm64. Actually using these
> requires checking the system_has_cmpxchg128() macro.
Yeah, that is what this series is doing..
Jason
next prev parent reply other threads:[~2024-11-07 13:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-01 16:22 [PATCH v9 00/10] iommu/amd: Use 128-bit cmpxchg operation to update DTE Suravee Suthikulpanit
2024-11-01 16:22 ` [PATCH v9 01/10] iommu/amd: Misc ACPI IVRS debug info clean up Suravee Suthikulpanit
2024-11-01 16:22 ` [PATCH v9 02/10] iommu/amd: Disable AMD IOMMU if CMPXCHG16B feature is not supported Suravee Suthikulpanit
2024-11-01 16:22 ` [PATCH v9 03/10] asm/rwonce: Introduce [READ|WRITE]_ONCE() support for __int128 Suravee Suthikulpanit
2024-11-05 12:30 ` Joerg Roedel
2024-11-06 8:55 ` Arnd Bergmann
2024-11-06 10:01 ` Uros Bizjak
2024-11-06 13:40 ` Jason Gunthorpe
2024-11-07 10:01 ` Arnd Bergmann
2024-11-07 10:30 ` Uros Bizjak
2024-11-07 13:37 ` Jason Gunthorpe [this message]
2024-11-07 13:47 ` Uros Bizjak
2024-11-01 16:22 ` [PATCH v9 04/10] iommu/amd: Introduce struct ivhd_dte_flags to store persistent DTE flags Suravee Suthikulpanit
2024-11-01 16:22 ` [PATCH v9 05/10] iommu/amd: Introduce helper function to update 256-bit DTE Suravee Suthikulpanit
2024-11-01 16:23 ` [PATCH v9 06/10] iommu/amd: Modify set_dte_entry() to use 256-bit DTE helpers Suravee Suthikulpanit
2024-11-01 16:32 ` Jason Gunthorpe
2024-11-01 16:23 ` [PATCH v9 07/10] iommu/amd: Introduce helper function get_dte256() Suravee Suthikulpanit
2024-11-01 16:23 ` [PATCH v9 08/10] iommu/amd: Modify clear_dte_entry() to avoid in-place update Suravee Suthikulpanit
2024-11-01 16:23 ` [PATCH v9 09/10] iommu/amd: Lock DTE before updating the entry with WRITE_ONCE() Suravee Suthikulpanit
2024-11-01 16:23 ` [PATCH v9 10/10] iommu/amd: Remove amd_iommu_apply_erratum_63() Suravee Suthikulpanit
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=20241107133725.GD520535@nvidia.com \
--to=jgg@nvidia.com \
--cc=arnd@arndb.de \
--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-arch@vger.kernel.org \
--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=ubizjak@gmail.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 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.