[Info-vax] Intel proposal to simplify x86-64

[Dan Cross]

In article <u5l89k$ddca$1 at dont-email.me>,
Simon Clubley  <clubley at remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2023-06-05, Dan Cross <cross at spitfire.i.gajendra.net> wrote:
>> Obviously, if the x86S proposal goes forward, the relevant code
>> bits in VMS will have to change.  I suspect VMS on x86_64 relies
>> on UEFI or a BIOS for DRAM training, so it can basically ignore
>> that; the FIT thing and SIPI startup may be a bit more
>> interesting, but fortunately, it's mostly in assembler and
>> really only a few dozen instructions so the change area will be
>> pretty small.
>>
>> There are good reasons for wanting to get into 16-bit mode
>> (mainly to grab services from a legacy BIOS for e.g. setting
>> graphics modes and things like that; pre 3.0 VBE etc) and
>> obviously that won't be supported anymore; I doubt it matters
>> much for VMS, however.
>
>_If_ I understand what you are saying correctly, then that would
>appear to mean existing versions of 64-bit operating systems are
>not compatible with this proposed new architecture, which means
>that you will need a new version of your existing 64-bit operating
>systems before it will boot on the new architecture.

Not necessarily, but with caveats.

In particular, this is not true if the OS in question already
supports direct entry in 64-bit mode.

There are several systems that work that way, but necessarily
rely on either a symbiotic loader that knows how to set up the
paged environment that they begin execution in, or a
well-defined boot protocol for handoff from a slightly more
generic loader.

For instance, Linux _can_ work this way, and supports 64-bit
entry with any loader that implements its 64-bit boot protocol:
https://www.kernel.org/doc/Documentation/x86/boot.txt

Note that Linux supports direct EFI handoff into a 64-bit entry
point.  A system that relies on that may need no change at all
to begin the boot process (the change would be invisibly handled
in firmware).

To an extent this is splitting hairs: system software that
boots into an OS must necessarily change, but that may not be
the OS itself.  For systems that rely on UEFI to boot, it may
require no changes _to the OS_ at all to get the BSP running.

However, the OS usually wants to handle bringing the AP CPUs
online itself, and for that, the OS will need some modification
(hence the caveat).  There is a UEFI protocol for MP management
but I don't believe it handles startup (I do not know, though).

I have no idea how VMS on x86_64 boots currently.  If it does
its own transition through 16- and 32-bit modes, or if it uses
multiboot and starts in 32-bit mode, that will have to change.
But I suspect the delta would be relatively small.

>Furthermore, it would _appear_ the new version will not run on the
>existing hardware. Do I understand the situation correctly ?

Not necessarily.  First, consider that almost no production
operating systems running on x86 start directly from the reset
vector; execution almost always starts in firmware, and then
_most_ use a multistage loader to boot into the actual operating
system.  This prevents a chicken-and-egg problem, where the OS
image may be resident on a non-trivial device that needs to be
initialized after reset.  Anyway, the point is that it is rarely
the case that the first instruction an x86 CPU runs when it
comes up is part of the actual operating system that will end
up running on that machine. [*]

Given that, nothing prevents an OS from having multiple entry
points exposing different boot protocols for variations in the
underlying hardware/firmware combination.  As long as a loader
that understands the system selects the correct one for the
architecture, it can do the right thing.

AP startup is fairly straight-forward here; the proposed new
system exposes CPUID bits that the OS can use to select either
the legacy or new AP boot method.

>_If_ my understanding is correct, then that would cause some real
>costs with management of systems in the real world that's going to
>really slow down adoption of the new architecture, until people are
>forced to switch due to the lack of old-style hardware.

I don't think the situation is quite as dire as that.

	- Dan C.

[*] An exception is our machine, which boots into a very thin
loader directly from reset; that is responsible for loading Unix
as a regular ELF binary, and then jumps directly to its entry
point.