Re: [PATCH 3/4] x86/kexec: Invalidate the IDT earlier in kexec_reloc()

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 24/03/2026 1:10 pm, Jan Beulich wrote:
> On 19.03.2026 13:25, Andrew Cooper wrote:
>> After switching stack, it is not safe to run any exception handlers, because
>> attempts to access the cpu_info block are out-of-bounds and will generate 
>> wild
>> accesses.
>>
>> Invalidating the IDT in the common path means there's no need to do so again
>> in the 32bit path, so drop compat_mode_idt entirely.
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Thanks.

>
> Yet still two suggestions:
>
>> --- a/xen/arch/x86/x86_64/kexec_reloc.S
>> +++ b/xen/arch/x86/x86_64/kexec_reloc.S
>> @@ -44,6 +44,16 @@ FUNC(kexec_reloc, PAGE_SIZE)
>>  
>>          movq    %rcx, %rbp
>>  
>> +        /*
>> +         * Invalidate the IDT.  After switching off Xen's stacks, the
>> +         * exception handlers are unsafe to use, because there's no way to
>> +         * perform arithmetic on the stack pointer to find the cpu_info 
>> block.
>> +         */
>> +        push    $0
>> +        pushw   $0
>> +        lidt    (%rsp)
>> +        add     $10, %rsp
> Deliberately misaligning the stack is odd (but not technically a problem of
> course). How about using two full PUSHes instead, possibly adding a 
> displacement
> of 6 to the LIDT in exchange?

I've got a similar pattern in a followup series to remove compat_gdt,
and for that it does strictly matter that it's not two full pushes.

This form takes no displacement and gets the accesses naturally aligned.

> Furthermore, don't we still have access to the full Xen image at this point? 
> If
> so, why not do the above without using the stack, using zero_page(%rip) (or
> zero_page+6(%rip))?

We're crashing.  I'll trust something freshly zeroed on the stack far
more than a piece of memory we'd never notice changing away from 0.

~Andrew