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

[Dan Cross]

In article <u5i3dr$3v85o$1 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 6/3/2023 9:57 AM, John Dallman wrote:
>> Intel are considering a simplification of x86-64, removing the 16-bit and
>> 32-bit modes, and changing the booting process, but retaining the ability
>> to run 32-bit applications under a 64-bit OS.
>> 
>> <https://www.intel.com/content/www/us/en/developer/articles/technical/envi
>> sioning-future-simplified-architecture.html>
>> 
>> Ring 0 will no longer be available to 32-bit code, and rings 1 and 2 will
>> no longer be available at all. I don't know much about how VMS on x86-64
>> emulates the four ring-equivalents that were available on VAX, Alpha and
>> Itanium, but it seemed worth raising the issue, while Intel are taking
>> comments on the plan.
>
>I am not an expert on such matters but it is my impression that:
>- Intel only want to change 32 bit stuff
>- VMS x86-64 does not use any 32 bit stuff

Architecturally, current x86_64 cores start up in 16-bit "real"
mode when they come out of reset (or power-on), and software
must transition them into a 64-bit state with paging enabled.
Usually this is done by moving into 32-bit "protected" mode,
enabing paging, and then jumping into "long" mode.

Sometimes this is done in a bootloader before an operating
system proper is started; often, a loader will enter the OS in
32-bit mode with paging disabled and rely on the OS to set up
a paging environment as it sees fit.

Further, multi-processor startup on x86 involves sending a
series of inter-processor interrupts from a specially blessed
"Bootstrap Processor" (Intel's nomenclature; AMD calls it the
"Bootstrap Core" or sometimes "Boot Support Core") to the "APs"
(Applicaton Processors), which also start in 16-bit mode where
software must similarly move them into something reasonable.

The x86S proposal changes this.  Systems will always begin
execution in 64-bit paged mode (including the BSP).  For APs
this is relatively straightforward: an architecturally defined
data structure that contains an initial program counter and to a
page table root is being introduced, along with a global MSR
that contains the physical address of an instance of that data
structure; presumably, the BSP creates this, sets the MSR, and
sends a "Startup IPI" (SIPI) to a core as it does now.

For the BSP this is more complex: a "firmware interface table"
contains the instruction pointer and a page table root pointer
that the BSP will begin execution with.  What's less clear is
what creates the initial page tables that the CPU comes out of
reset running against (let alone creates that table).
Furthermore, many current Intel systems rely on software running
on the x86 cores for DRAM timing training; usually this is done
by basically treating cache as RAM and running entirely in
cached memory initially; if paging is introduced into the mix
that early, it's not clear how that will happen.  On AMD, for
e.g. EPYC, this is done by the PSP (Platform Security Processor)
before the x86 cores come out of reset; it's possible Intel may
take a similar approach here.

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.

	- Dan C.