[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7BB09BB9-7034-413B-9FA8-D3FC3EB352D7@zytor.com>
Date: Sat, 25 Oct 2025 14:50:08 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Dave Hansen <dave.hansen@...el.com>, Usama Arif <usamaarif642@...il.com>,
dwmw@...zon.co.uk, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, ardb@...nel.org
CC: x86@...nel.org, apopple@...dia.com, thuth@...hat.com, nik.borisov@...e.com,
kas@...nel.org, linux-kernel@...r.kernel.org,
linux-efi@...r.kernel.org, kernel-team@...a.com,
Michael van der Westhuizen <rmikey@...a.com>,
Tobias Fleig <tfleig@...a.com>
Subject: Re: [PATCH 1/3] x86/boot: Fix page table access in 5-level to 4-level paging transition
On October 22, 2025 4:16:34 PM PDT, Dave Hansen <dave.hansen@...el.com> wrote:
>On 10/22/25 15:06, Usama Arif wrote:
>> + pgdp = (pgd_t *)read_cr3_pa();
>> + new_cr3 = (u64 *)(pgd_val(pgdp[0]) & PTE_PFN_MASK);
>> + memcpy(trampoline_32bit, new_cr3, PAGE_SIZE);
>
>Heh, somebody like casting, I see!
>
>But seriously, read_cr3_pa() should be returning a physical address. No?
>Today it does:
>
>static inline unsigned long read_cr3_pa(void)
>{
> return __read_cr3() & CR3_ADDR_MASK;
>}
>
>So shouldn't CR3_ADDR_MASK be masking out any naughty non-address bits?
>Shouldn't we fix read_cr3_pa() and not do this in its caller?
Ah, the times when one can wish for C++.
Too bad they still haven't figured out tagged initializers.
Powered by blists - more mailing lists