All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Will Deacon <will@kernel.org>, Joey Gouly <joey.gouly@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	David Hildenbrand <david@redhat.com>,
	Peter Xu <peterx@redhat.com>, Mike Rapoport <rppt@linux.ibm.com>,
	Shivansh Vij <shivanshvij@outlook.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] arm64/mm: Move PTE_INVALID to overlay PTE_NS
Date: Mon, 29 Apr 2024 17:34:01 +0100	[thread overview]
Message-ID: <Zi_L-asPXKDo3IMf@arm.com> (raw)
In-Reply-To: <20240429140208.238056-3-ryan.roberts@arm.com>

On Mon, Apr 29, 2024 at 03:02:06PM +0100, Ryan Roberts wrote:
> PTE_INVALID was previously occupying bit 59, which when a PTE is valid
> can either be IGNORED, PBHA[0] or AttrIndex[3], depending on the HW
> configuration. In practice this is currently not a problem because
> PTE_INVALID can only be 1 when PTE_VALID=0 and upstream Linux always
> requires the bit set to 0 for a valid pte.
> 
> However, if in future Linux wants to use the field (e.g. AttrIndex[3])
> then we could end up with confusion when PTE_INVALID comes along and
> corrupts the field - we would ideally want to preserve it even for an
> invalid (but present) pte.
> 
> The other problem with bit 59 is that it prevents the offset field of a
> swap entry within a swap pte from growing beyond 51 bits. By moving
> PTE_INVALID to a low bit we can lay the swap pte out so that the
> offset field could grow to 53 bits in future.
> 
> So let's move PTE_INVALID to overlay PTE_NS (bit 5). PTE_NS is res0 for
> SW outside of the secure state so Linux will never need to touch it.
> 
> These are both marginal benefits, but make things a bit tidier in my
> opinion.
> 
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

(subject to renaming PTE_INVALID to PTE_PRESENT_INVALID)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Ryan Roberts <ryan.roberts@arm.com>
Cc: Will Deacon <will@kernel.org>, Joey Gouly <joey.gouly@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	David Hildenbrand <david@redhat.com>,
	Peter Xu <peterx@redhat.com>, Mike Rapoport <rppt@linux.ibm.com>,
	Shivansh Vij <shivanshvij@outlook.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] arm64/mm: Move PTE_INVALID to overlay PTE_NS
Date: Mon, 29 Apr 2024 17:34:01 +0100	[thread overview]
Message-ID: <Zi_L-asPXKDo3IMf@arm.com> (raw)
In-Reply-To: <20240429140208.238056-3-ryan.roberts@arm.com>

On Mon, Apr 29, 2024 at 03:02:06PM +0100, Ryan Roberts wrote:
> PTE_INVALID was previously occupying bit 59, which when a PTE is valid
> can either be IGNORED, PBHA[0] or AttrIndex[3], depending on the HW
> configuration. In practice this is currently not a problem because
> PTE_INVALID can only be 1 when PTE_VALID=0 and upstream Linux always
> requires the bit set to 0 for a valid pte.
> 
> However, if in future Linux wants to use the field (e.g. AttrIndex[3])
> then we could end up with confusion when PTE_INVALID comes along and
> corrupts the field - we would ideally want to preserve it even for an
> invalid (but present) pte.
> 
> The other problem with bit 59 is that it prevents the offset field of a
> swap entry within a swap pte from growing beyond 51 bits. By moving
> PTE_INVALID to a low bit we can lay the swap pte out so that the
> offset field could grow to 53 bits in future.
> 
> So let's move PTE_INVALID to overlay PTE_NS (bit 5). PTE_NS is res0 for
> SW outside of the secure state so Linux will never need to touch it.
> 
> These are both marginal benefits, but make things a bit tidier in my
> opinion.
> 
> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>

(subject to renaming PTE_INVALID to PTE_PRESENT_INVALID)

  reply	other threads:[~2024-04-29 16:34 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-29 14:02 [PATCH v2 0/3] arm64/mm: Enable userfaultfd write-protect Ryan Roberts
2024-04-29 14:02 ` Ryan Roberts
2024-04-29 14:02 ` [PATCH v2 1/3] arm64/mm: Refactor PMD_PRESENT_INVALID and PTE_PROT_NONE bits Ryan Roberts
2024-04-29 14:02   ` Ryan Roberts
2024-04-29 16:12   ` David Hildenbrand
2024-04-29 16:12     ` David Hildenbrand
2024-04-29 16:20   ` Catalin Marinas
2024-04-29 16:20     ` Catalin Marinas
2024-04-29 17:15     ` Ryan Roberts
2024-04-29 17:15       ` Ryan Roberts
2024-04-30 11:11       ` Catalin Marinas
2024-04-30 11:11         ` Catalin Marinas
2024-04-30 11:35         ` Ryan Roberts
2024-04-30 11:35           ` Ryan Roberts
2024-04-30 13:28           ` Catalin Marinas
2024-04-30 13:28             ` Catalin Marinas
2024-04-30 13:34             ` Ryan Roberts
2024-04-30 13:34               ` Ryan Roberts
2024-04-30 11:37         ` David Hildenbrand
2024-04-30 11:37           ` David Hildenbrand
2024-04-30 12:53           ` Ryan Roberts
2024-04-30 12:53             ` Ryan Roberts
2024-04-30 12:58             ` David Hildenbrand
2024-04-30 12:58               ` David Hildenbrand
2024-04-30 13:30   ` Will Deacon
2024-04-30 13:30     ` Will Deacon
2024-04-30 14:02     ` Ryan Roberts
2024-04-30 14:02       ` Ryan Roberts
2024-04-30 15:04       ` Will Deacon
2024-04-30 15:04         ` Will Deacon
2024-04-30 15:39         ` Ryan Roberts
2024-04-30 15:39           ` Ryan Roberts
2024-04-29 14:02 ` [PATCH v2 2/3] arm64/mm: Move PTE_INVALID to overlay PTE_NS Ryan Roberts
2024-04-29 14:02   ` Ryan Roberts
2024-04-29 16:34   ` Catalin Marinas [this message]
2024-04-29 16:34     ` Catalin Marinas
2024-04-29 14:02 ` [PATCH v2 3/3] arm64/mm: Add uffd write-protect support Ryan Roberts
2024-04-29 14:02   ` Ryan Roberts
2024-04-29 16:08   ` David Hildenbrand
2024-04-29 16:08     ` David Hildenbrand

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=Zi_L-asPXKDo3IMf@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=david@redhat.com \
    --cc=joey.gouly@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=peterx@redhat.com \
    --cc=rppt@linux.ibm.com \
    --cc=ryan.roberts@arm.com \
    --cc=shivanshvij@outlook.com \
    --cc=will@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 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.