Re: [Xen-devel] [PATCH] x86/boot: Drop vestigial support for pre-SIPI APICs

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 12/06/2019 12:51, Jan Beulich wrote:
>>>> On 12.06.19 at 13:05, <andrew.cooper3@xxxxxxxxxx> wrote:
>> The current code in do_boot_cpu() makes a CMOS write (even in the case of an
>> FADT reduced hardware configuration) and two writes into the BDA for the
>> start_eip segment and offset.
>>
>> BDA 0x67 and 0x69 hail from the days of the DOS and the 286, when IBM put
>> together the fast way to return from Protected mode back to Real mode (via a
>> deliberate triple fault).  This vector, when set, redirects the early boot
>> logic back into OS control.
>>
>> It is also used by early MP systems, before the Startup IPI message became
>> standard, which in practice was before Local APICs became integrated into CPU
>> cores.
>>
>> Support for non-integrated APICs was dropped in c/s 7b0007af "xen/x86: Remove
>> APIC_INTEGRATED() checks" because there are no 64-bit capable systems without
>> them.  Therefore, drop smpboot_{setup,restore}_warm_reset_vector().
>>
>> Dropping smpboot_setup_warm_reset_vector() also lets us drop
>> TRAMPOLINE_{HIGH,LOW}, which lets us drop mach_wakecpu.h entirely.  The final
>> function in smpboot_hooks.h is smpboot_setup_io_apic() and has a single
>> caller, so expand it inline and delete smpboot_hooks.h as well.
>>
>> This removes all reliance on CMOS and the BDA from the AP boot path, which is
>> especially of interest on reduced_hardware boots and EFI systems.
>>
>> Reported-by: David Woodhouse <dwmw@xxxxxxxxxxxx>
> Does this mean there was an actual problem resulting from this code
> being there, or simply the observation that this code is all dead?
> Clarifying one way or the other by half a sentence would be nice.

It was more an observation that when you kexec Xen, it blindly writes
into the BDA even when that wasn't set up properly by the tools.

Arguably that may have been kexec setup problem more than a Xen problem,
but after looking at this code, it is obviously that what Xen was doing
definitely wasn't right to do unconditionally.  It just so happens that
it safe to unconditionally drop the logic, rather than to make it
dependant on other system properties.

I'm not sure how best to phrase this.

>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

Thanks,

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel