Re: [PATCH 1/9] x86/kexec: Disable global pages before writing to control page

[David Woodhouse]

On 17 December 2024 13:25:48 CET, "Kirill A. Shutemov" <kirill.shutemov at linux.intel.com> wrote:
>On Mon, Dec 16, 2024 at 11:24:08PM +0000, David Woodhouse wrote:
>> From: David Woodhouse <dwmw at amazon.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...