[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D5246E62-F850-4869-8365-0399E0C1C82A@infradead.org>
Date: Tue, 17 Dec 2024 13:39:01 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
CC: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
Eric Biederman <ebiederm@...ssion.com>, David Woodhouse <dwmw@...zon.co.uk>,
Sourabh Jain <sourabhjain@...ux.ibm.com>,
Hari Bathini <hbathini@...ux.ibm.com>, Michael Ellerman <mpe@...erman.id.au>,
Thomas Zimmermann <tzimmermann@...e.de>,
Andrew Morton <akpm@...ux-foundation.org>, Baoquan He <bhe@...hat.com>,
Yuntao Wang <ytcoode@...il.com>, David Kaplan <david.kaplan@....com>,
Tao Liu <ltao@...hat.com>, Kai Huang <kai.huang@...el.com>,
Ard Biesheuvel <ardb@...nel.org>, Josh Poimboeuf <jpoimboe@...nel.org>,
Breno Leitao <leitao@...ian.org>, Wei Yang <richard.weiyang@...il.com>,
Rong Xu <xur@...gle.com>,
Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
Simon Horman <horms@...nel.org>, Dave Young <dyoung@...hat.com>,
Peter Zijlstra <peterz@...radead.org>, bsz@...zon.de, nathan@...nel.org
Subject: Re: [PATCH 1/9] x86/kexec: Disable global pages before writing to control page
On 17 December 2024 13:25:48 CET, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com> wrote:
>On Mon, Dec 16, 2024 at 11:24:08PM +0000, David Woodhouse wrote:
>> From: David Woodhouse <dwmw@...zon.co.uk>
>>
>> The kernel switches to a new set of page tables during kexec. The global
>> mappings (_PAGE_GLOBAL==1) can remain in the TLB after this switch. This
>> is generally not a problem because the new page tables use a different
>> portion of the virtual address space than the normal kernel mappings.
>>
>> The critical exception to that generalisation (and the only mapping
>> which isn't an identity mapping) is the kexec control page itself —
>> which was ROX in the original kernel mapping, but should be RWX in the
>> new page tables. If there is a global TLB entry for that in its prior
>> read-only state, it definitely needs to be flushed before attempting to
>> write through that virtual mapping.
>>
>> It would be possible to just avoid writing to the virtual address of the
>> page and defer all writes until they can be done through the identity
>> mapping. But there's no good reason to keep the old TLB entries around,
>> as they can cause nothing but trouble.
>>
>> Clear the PGE bit in %cr4 early, before storing data in the control page.
>
>It worth noting that flipping CR4.PGE triggers TLB flush. I was not sure
>if CR3 write is required to make it happen.
Well, until we flip to the new CR3 the read-only PTE can just get reloaded. But after CR4.PGE is cleared, of course they won't be global any more. So they will get flushed (again) when CR3 is reloaded.
Maybe it could run a tiny bit faster if we change CR3 before CR4? I don't know that we care about microbenchmarking kexec to that degree, but I may take a look...
Powered by blists - more mailing lists