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

[Dan Cross]

In article <u5oe7n$9s6$1 at panix2.panix.com>,
Scott Dorsey <kludge at panix.com> wrote:
>Johnny Billquist  <bqt at softjar.se> wrote:
>>On 2023-06-06 19:55, Scott Dorsey wrote:
>>> John Dallman <jgd at cix.co.uk> wrote:
>>>> In article <63a25e5a-2001-451b-b8a7-d6d9e74b02f9n at googlegroups.com>,
>>>> xyzzy1959 at gmail.com (John Reagan) wrote:
>>>>
>>>>> Other than an impact on the boot loader due to the change in
>>>>> startup mode, it has essentially no impact on OpenVMS
>>>>>
>>>>> OpenVMS does not use ring 1 or 2.  The 64-bit mode PTEs don't
>>>>> include support for ring 1 or 2 today, just ring 0 and 3.
>>>>
>>>> Thanks, glad to hear it.
>>> 
>>> I'm not necessarily glad to hear it because I like the idea of keeping
>>> device drivers in a different ring than user processes or kernel....
>>
>>Hmm. Am I misremembering something? As far as I can recall, device 
>>drivers in VMS (at least on VAX) are running in kernel mode. RMS in EXEC 
>>and DCL in SUPER (or was it the other way around?).
>
>Yes.  It's a shame.  When the new i386 rings came out I was thinking 
>"Wow, we could do Honeywell-style stuff and it's not a mess like the
>286 but... then nobody ever did.

I guess I don't really see how.

If you look at the ring architecture of, say, the GE-645
machines, the ring was an attribute of a segment for permission
checking by the hardware, but each segment was independently
paged (with its own page table).  Put another way, the Honeywell
architectures built paging on top of segmentation, allowing them
to easily support paged segments: necessary when multiplexing a
large virtual address space over a limited physical memory.
Furthermore, Multics-style segments can exist in multiple rings
at one time.

The 80386 had no such provisions.  And while x86 segment
descriptors do encode a ring level for privilege checking, and
the granularity bit introduced in the '386 allows segments to
address more than 64k of memory, segments are neither
independently paged nor do they support the Honeywell
bracketing technqiue, so sharing segments between tasks without
call gating is hard.

Further, x86 segments don't compose well with paging, and thus
aren't well-suited for multiplexing over a smaller physical
memory.  Unlike the DPS-8/M, when paging is enabled on x86, the
paged virtual address space creates a large linear address space
that segments sit on top of.  That is, x86 segments are
structurally the inverse of independently-paged Multics machine
segments.  This means you can't have, say, copy-on-write at
page granularity across different segments: all segments
containing a page either map that page or don't.

Also, since the paging structure itself is practically unaware
of the ring architecture, providing only a single bit to select
between user (ring 3) or supervisor (ring <3) access,
the implication is that paged segments in any ring other than 3
can access any page in the linear space; there's no way to
enforce that, say, a page accessible at ring 0 is not accessible
at ring 1 or 2.  This makes sharing between segments at the page
granularity practically impossible; see also no ring bracketing.

Of course, one can ignore paging entirely and _just_ use
segments, but now you essentially cannot mux them over a
relatively small physical memory at less than segment
granularity.

So what really is the point?

	- Dan C.