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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.06.19 at 13:55, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

Maybe "In practice issues with this were observed only with kexec"?

Jan



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