linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Bharata B Rao <bharata@amd.com>
To: Dave Hansen <dave.hansen@intel.com>, linux-kernel@vger.kernel.org
Cc: linux-mm@kvack.org, x86@kernel.org,
	kirill.shutemov@linux.intel.com, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
	catalin.marinas@arm.com, will@kernel.org, shuah@kernel.org,
	oleg@redhat.com, ananth.narayan@amd.com
Subject: Re: [RFC PATCH v0 0/6] x86/AMD: Userspace address tagging
Date: Mon, 14 Mar 2022 10:30:09 +0530	[thread overview]
Message-ID: <57338b2a-291c-c7e7-57d5-86a8468b619f@amd.com> (raw)
In-Reply-To: <81b6f618-05bc-f7d0-5461-4c3f0ca42d3f@intel.com>

On 3/10/2022 8:46 PM, Dave Hansen wrote:
> On 3/10/22 03:15, Bharata B Rao wrote:>
>> This patchset builds on that prctl() extension and adds support
>> for AMD UAI. AMD implementation is kept separate as equivalent
>> Intel LAM implementation is likely to be different due to different
>> bit positions and tag width.
> 
> Please don't keep the implementations separate.
> 
> We'll have one x86 implementation of address bit masking.  Both the
> Intel and AMD implementations will feed into a shared implementation.
> Something _like_ the cc_set_mask() interface where both implementations
> do their detection and then call into common code to say how many bits
> are being ignored.

The difference isn't limited to the number of ignored bits, see below...

> 
> A good litmus test for this is how many vendor-specific checks there are
> in common code.  If there are a lot of them, it's not a good sign for
> the design.

That is generally true but considering the below differences, I felt it
was much cleaner to go for separate implementations for enablement and
untagging while still building on the common prctl() extension in the
RFC version.

1. While Intel LAM provides two LAM widths (15 and 6 bits wide), AMD UAI
has a fixed tag width of 7 bits. This results in following differences
in the implementation:
   - Two threadinfo flags (TIF_LAM_57 and TIF_LAM_48) in Intel LAM vs
     single flag TIF_TAGGED_ADDR(like in ARM64) in AMD UAI.
   - Untagging needs to be aware of 2 widths in Intel LAM as against
     a single width in AMD UAI.
   - Requirement of making LAM_U48 and mappings above 47bits mutually
     exclusive is required for Intel LAM only.

2. The enablement bit is part of CR3 in Intel LAM which brings in
additional complexity of updating the CR3 with right LAM mode on every
MM switch and associated tlbstate changes. In AMD UAI, enablement bit
is part of EFER MSR and it is a single time enablement with no MM switch
time changes.

However, let me take a detailed look once again and explore further
code sharing possibilities.

Regards,
Bharata.


  parent reply	other threads:[~2022-03-14  5:00 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-10 11:15 [RFC PATCH v0 0/6] x86/AMD: Userspace address tagging Bharata B Rao
2022-03-10 11:15 ` [RFC PATCH v0 1/6] mm, arm64: Update PR_SET/GET_TAGGED_ADDR_CTRL interface Bharata B Rao
2022-03-10 11:15 ` [RFC PATCH v0 2/6] x86/cpufeatures: Add Upper Address Ignore(UAI) as CPU feature Bharata B Rao
2022-03-10 11:15 ` [RFC PATCH v0 3/6] x86: Enable Upper Address Ignore(UAI) feature Bharata B Rao
2022-03-10 19:46   ` Andrew Cooper
2022-03-10 22:37     ` David Laight
2022-03-10 22:46       ` Dave Hansen
2022-03-11 12:37   ` Boris Petkov
2022-03-10 11:15 ` [RFC PATCH v0 4/6] x86: Provide an implementation of untagged_addr() Bharata B Rao
2022-03-10 11:15 ` [RFC PATCH v0 5/6] x86: Untag user pointers in access_ok() Bharata B Rao
2022-03-10 11:15 ` [RFC PATCH v0 6/6] x86: Add prctl() options to control tagged user addresses ABI Bharata B Rao
2022-03-10 14:32 ` [RFC PATCH v0 0/6] x86/AMD: Userspace address tagging David Laight
2022-03-10 16:45   ` Dave Hansen
2022-03-10 17:19     ` David Laight
2022-03-11  5:42       ` Bharata B Rao
2022-03-11  8:15         ` David Laight
2022-03-11  9:11           ` Bharata B Rao
2022-03-11  9:36             ` David Laight
2022-03-11 16:51               ` Dave Hansen
2022-03-10 15:16 ` Dave Hansen
2022-03-10 15:22   ` Dave Hansen
2022-03-14  5:00   ` Bharata B Rao [this message]
2022-03-14  7:03     ` Dave Hansen
2022-03-21 22:29 ` Andy Lutomirski
2022-03-21 22:59   ` Thomas Gleixner
2022-03-22  5:31   ` David Laight
2022-03-23  7:48   ` Bharata B Rao
2022-04-01 19:25     ` Dave Hansen
2022-04-05  5:58       ` Bharata B Rao
2022-04-01 19:41     ` Andy Lutomirski
2022-04-05  8:14     ` Peter Zijlstra
2022-04-05  8:40       ` Bharata B Rao
2022-04-08 17:41   ` Catalin Marinas

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=57338b2a-291c-c7e7-57d5-86a8468b619f@amd.com \
    --to=bharata@amd.com \
    --cc=ananth.narayan@amd.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).