arch/x86_64: Terrible, awful hackery to bootstrap entry
arch/x86_64: Terrible, awful hackery to bootstrap entry

Because of a historical misunderstanding, by default the ACRN
hypervisor wants to load Zephyr at address 0x1000 and enter the binary
at that same address.  This entry point corresponds to the __start
symbol of the build they were given, which is a 1-cpu non-SMP
configuration.  Unfortunately, when we build with
CONFIG_MP_NUM_CPUS=1, the code in locore.S #if's out the 16 bit entry
point for the auxiliary CPUs at the start of the section.  So in the
build ACRN received, the start address happened to be 0x7000, the same
address we need to launch the AP processors from.

That's right: under ACRN, the SAME ADDRESS used to enter the OS in 32
bit mode needs to be used later to boot CPUs running in 16 bit real
mode!

The solution, such as it is, is to put a 32 bit jump at the entry
address which hops to the 32 bit OS entry code, and then scribble NOP
instructions over that jump once we get there so that the next time we
reach that address (in real mode) we fall through to the correct
entry.

This patch should be considered a temporary workaround.  While it
works on all x86 hardware, it's not really needed.  A much better
solution would be to eliminate the locore linker region entirely
(which causes other headaches) and enter the Zephyr binary in a 32 bit
address somewhere in the contiguous high memory area.  All that locore
is needed for is the 16 bit bootstrap code for SMP processors, which
is ~6 instructions and can be copied in from the kernel at runtime.

Signed-off-by: Andy Ross <c70f9a6bf6ee0cd69c8af4ce5e6b131945769315@intel.com>

galak/zephyr,zephyrproject-rtos/zephyr,finikorg/zephyr,galak/zephyr,zephyrproject-rtos/zephyr,finikorg/zephyr,zephyrproject-rtos/zephyr,galak/zephyr,finikorg/zephyr,galak/zephyr,finikorg/zephyr,zephyrproject-rtos/zephyr,zephyrproject-rtos/zephyr,finikorg/zephyr,galak/zephyr