[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0d3f7e60-48e3-4b02-90d7-207868d3311f@arm.com>
Date: Tue, 15 Oct 2024 12:17:47 +0530
From: Anshuman Khandual <anshuman.khandual@....com>
To: Ryan Roberts <ryan.roberts@....com>, linux-arm-kernel@...ts.infradead.org
Cc: Marc Zyngier <maz@...nel.org>, Oliver Upton <oliver.upton@...ux.dev>,
James Morse <james.morse@....com>, Catalin Marinas
<catalin.marinas@....com>, Will Deacon <will@...nel.org>,
Ard Biesheuvel <ardb@...nel.org>, Mark Rutland <mark.rutland@....com>,
kvmarm@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/5] arm64/mm: Drop PXD_TABLE_BIT
On 10/9/24 19:02, Ryan Roberts wrote:
> On 05/10/2024 13:38, Anshuman Khandual wrote:
>> Clearing PXD_TABLE_BIT i.e bit[1] on a page table entry always operates on
>> the assumption that subsequent PXD_VALID i.e bit[0] is set. That's because
>> bits[1:0]="01" makes a block mapping. So it is prudent to treat bits[1:0]
>> as a single register field, which should be updated as block or table etc.
>> Although mk_[pmd|pud]_sect_prot() helpers go to some extent in using these
>> PXD_TYPE_SECT macros, their usage is not really consistent else where.
>>
>> This series removes these table bit clearing for block mapping creation and
>> eventually completely drops off those table macros.
> Given the issue I just noticed in patch 2, I'm not sure if it's going to be
> practical to remove the table bit after all? Sorry I didn't spot this before.
Now that arch_make_huge_pte() seems to be all good in patch 1, and there might
be a solution for pmd_present() via de-coupled pmd_mkinvalid(), would it still
not possible to drop PXD_TABLE_BIT ?
Powered by blists - more mailing lists