more virtualization-inspired ramblings: mstatus.VM

[Paolo Bonzini]

One of the aspects of the RISC-V privileged architecture that puzzled me
the most is that VM is not part of sstatus. Yet, there's no way to set
it via SBI, so the OS must know how to deal with whatever page table
format has been set by M-mode code.

In addition, M-mode and S-mode translation are not stackable. Some
type-1 hypervisors in the past (e.g. Xen on 32-bit x86, which ran the
guest kernel in x86 ring 1) have used single base-and-bound to protect
themselves from the guests, so I'm introducing a similar mechanism in
this proposal to allow the M-mode monitor to protect itself from
H/S/U-mode code.

Other parts of the idea are inspired of course by virtualization, and
I'll note them along the way.

The idea is to change the VM[4:0] field into three fields, also
totaling five bits:

- a one-bit MVM field (WARL):

0 = no protection (Mbare) or single base-and-bound (Mbb)
1 = separate instruction and data base-and-bound (Mbbid)

To represent lack of support for Mbb, mbase/mbound are WARL in my
proposal, and hard-coded to all-zeros/all-ones if Mbb if unsupported.
Emulating Mbb on top of Mbbid works as in the spec.

If Mbb is supported, the only way to disable protection is to write
0 to mbase and ~0 to mbound.

Because MVM and SVM are separated, the base and bound are applied (if
supported) even to "physical" addresses computed from supervisor
mode page tables. See also the "Privilege Spec terminology change"
thread from August 19th proposal where Samuel Falvo proposed
multiple-stage U->S->M translation


- a two-bit reserved field, which will become HVM and is visible in
hstatus; they will be somewhat related to two-level address
translation, and could come in handy with or without my other proposal
on S-mode hypervisors.


- a two-bit SVM field (WARL), visible in hstatus and sstatus, with the
following meaning:

00 = no page translation, sptbr ignored
01 = 32-bit virtual addresses with RV32 sptbr format (Sv32)
10 = RV64 sptbr format
11 = reserved

In other words the Sv32 format for page tables is usable in RV64
too. This could come in handy to virtualize RV32 guests on top of
RV64; it also limits the amount of memory used for page tables on
small machines at the cost of a limited virtual address space. In
the 1.9 spec, instead, Sv32 is RV32-only while RV64 is limited to
Sv39 and Sv48.

SVM being WARL, it is possible (perhaps desirable) for an
implementation to reject MVM == 1 && SVM != 00 (Mbbid + paging).


- a new representation for the RV64 sptbr:

bit 0-39 PPN (WARL)
bit 40-55 ASID (WARL)
bit 56-57 SVSZ (supervisor virtual address size, WLRL)
bit 58-63 reseved (WLRL)

The idea behind this is to limit mstatus's content to whatever
information is needed to parse sptbr. Once we know sptbr is a 64-bit
value, we can put the rest of the information in sptbr itself.

So I am adding room for more page-table flags and defining one.
Since I'm at it I'm adding a couple bits to the PPN, rounding the
number of ASIDs to a nice 2^16.

SVSZ is defined as:

00 39-bit virtual addresses (Sv39, three-level page tables)
01 48-bit virtual addresses (Sv48, four-level page tables)
10 Reserved for 57-bit virtual addresses
11 Reserved for 64-bit virtual addresses


Opinions? Probability of integrating any of my ideas (these, and some
kind of preparation to avoid baking too much of H mode into the spec)
before freezing? I know it's already 1.9...

Paolo

[Andrew Waterman]

Thanks for taking the time to think about these issues.

On Mon, Sep 19, 2016 at 8:05 AM, Paolo Bonzini <bon...@gnu.org> wrote:
> One of the aspects of the RISC-V privileged architecture that puzzled me
> the most is that VM is not part of sstatus. Yet, there's no way to set
> it via SBI, so the OS must know how to deal with whatever page table
> format has been set by M-mode code.

Our expectation is that the loader sets the VM field for the OS, and
then it would remain constant. A field in the ELF header could carry
this information.

>
> In addition, M-mode and S-mode translation are not stackable. Some
> type-1 hypervisors in the past (e.g. Xen on 32-bit x86, which ran the
> guest kernel in x86 ring 1) have used single base-and-bound to protect
> themselves from the guests, so I'm introducing a similar mechanism in
> this proposal to allow the M-mode monitor to protect itself from
> H/S/U-mode code.

Protection only, rather than an additional translation step, should
suffice for this purpose. PMAs can handle this.

This seems like a reasonable design to me, but I'm not yet convinced
supervisor software needs direct control over the page table depth
(and, if it does, whether an SBI call would suffice).

Does exposing this option directly to the OS complicate hypervisor
implementation at all?

We're still amenable to changes prior to the next version, provided
compelling justification. We still haven't had time to think through
the implications of your hypervisor proposal from a few weeks ago, but
hope to do so soon.

>
> Paolo
>
> --
> You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
> To post to this group, send email to isa...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/3a3dd962-1a15-2b9a-7c4e-1cb2770e9b67%40gnu.org.

[Paolo Bonzini]

On 19/09/2016 19:55, Andrew Waterman wrote:
> Thanks for taking the time to think about these issues.
>
> On Mon, Sep 19, 2016 at 8:05 AM, Paolo Bonzini <bon...@gnu.org> wrote:
>> One of the aspects of the RISC-V privileged architecture that puzzled me
>> the most is that VM is not part of sstatus. Yet, there's no way to set
>> it via SBI, so the OS must know how to deal with whatever page table
>> format has been set by M-mode code.
>
> Our expectation is that the loader sets the VM field for the OS, and
> then it would remain constant. A field in the ELF header could carry
> this information.

Oh, I found it now: "once the machine is set up, the OS kernel is mapped
into virtual memory, and its entry point is called".

But where does the loader end and the OS start? For example, are U-Boot
or a UEFI environment a loader? Both are complicated enough that they
might want to set up paging, even if it's only to place a guard page on
the bottom of the stack. (On x86, we did have cases where the guard
page caught UEFI bugs due to an excessively small stack). What if their
page table format is different from that of the kernel they load?

Also, Linux is able to start another kernel with kexec. Why limit that
to a kernel with the same page table format?

Yeah, there's always the SBI route, but... it's really a hack. Chapter
9 says "Several features that might normally handled by the supervisor
operating system (OS) directly are handled via SBI calls to the SEE in
RISC-V" but it doesn't provide any rationale, and SBI right now is
mostly providing multi-processor services. There are a few exceptions
(console get/put, shutdown, mask/unmask interrupt---which is probably
not really a necessary part of the SBI either) but tweaking the page
table format doesn't fit any of them.

>> In addition, M-mode and S-mode translation are not stackable. Some
>> type-1 hypervisors in the past (e.g. Xen on 32-bit x86, which ran the
>> guest kernel in x86 ring 1) have used single base-and-bound to protect
>> themselves from the guests, so I'm introducing a similar mechanism in
>> this proposal to allow the M-mode monitor to protect itself from
>> H/S/U-mode code.
>
> Protection only, rather than an additional translation step, should
> suffice for this purpose. PMAs can handle this.

If stacking segmentation with paging is unnecessary, why even make
segmentation an M-mode concept, and paging an S-mode concept? Both
could be simply S-mode concepts, that naturally move up to M-mode if
S-mode doesn't exist.

(IOW, by allowing an M-mode monitor to sets up sptbr page tables for
U-mode code, paging can be made available on M,U implementations, rather
than only M,S,U as in Table 3.3. This removes an unnecessary difference
between the various RISC-V translation modes).

So with this observation mstatus.VM would be reduced to 2 bits only
(let's call them mstatus.SVM if they're then made visible in sstatus):

00 = Mbare or Mbb depending on mbase/mbound (well, sbase/sbound?...)
01 = Mbbid
10 = 32-bit virtual addresses with RV32 sptbr format (Sv32)
11 = RV64 sptbr format, page table depth contained in sptbr

For 00 and 01, segmentation would only be applied to U-mode and S-mode
would run with physical addresses just like M-mode. If S-mode exists,
M-mode protection would be left to PMA/PMP.

Actually I like this even more that the previous one! :)

>> - a new representation for the RV64 sptbr:
>>
>> bit 0-39 PPN (WARL)
>> bit 40-55 ASID (WARL)
>> bit 56-57 SVSZ (supervisor virtual address size, WLRL)
>> bit 58-63 reseved (WLRL)
>>

>> SVSZ is defined as:
>>
>> 00 39-bit virtual addresses (Sv39, three-level page tables)
>> 01 48-bit virtual addresses (Sv48, four-level page tables)
>> 10 Reserved for 57-bit virtual addresses
>> 11 Reserved for 64-bit virtual addresses
>

> This seems like a reasonable design to me, but I'm not yet convinced
> supervisor software needs direct control over the page table depth
> (and, if it does, whether an SBI call would suffice).
>
> Does exposing this option directly to the OS complicate hypervisor
> implementation at all?

Maybe I've not understood the question. It's _not_ exposing this option
that complicates the hypervisor, even without considering type-2
hypervisors, i.e. purely within the H-mode framework envisioned by the
1.9 spec.

The hypervisor has to deal with _three_ kinds of address translations:
the hypervisor page tables (H->M) and the two translation levels for the
guest page tables (Svirtual->Sphysical from sptbr, and Sphysical->M).
Just to make things simple let's say you use the same page format for
H->M and Sphysical->M (it is an arbitrary limitation---but it's one that
I could live with).

But, different guests may well demand different sizes for the
Svirtual->Sphysical translation.

Therefore the hypervisor _really_ needs control on that one, and it has
to change it fast because it is part of the hypervisor context switch;
so you really need to configure Svirtual->Sphysical with a knob that
isn't mstatus.VM.

The good news is that you won't have any problem fitting the page
formats in mstatus.VM (there are 8 values in use out of 32, and you'll
only need 5 more if the same format controls hptbr and hsptbr).

The ugly news is that the sptbr page table format would be defined by
mstatus.vm on bare-metal and by something else when running under
H-mode. This something else would presumably be some field in hstatus
and it would waste several precious bits in mstatus (this is the bad news).

It's frankly very messy, in English and probably in the HDL too; it
sounds even more messy if the solution is obvious, i.e. let whoever sets
up the page tables pick the format they desire. So for sptbr that's the
S-mode code itself; and then putting the format in sptbr rather than
sstatus is the obvious way to save on mstatus bits.

> We're still amenable to changes prior to the next version, provided
> compelling justification. We still haven't had time to think through
> the implications of your hypervisor proposal from a few weeks ago, but
> hope to do so soon.

Great, thanks. FWIW, I would already be very happy if you just removed
all traces of H mode from the spec. :)

(And sorry if I sound excessively negative. There's plenty of great
stuff of course!).

Paolo

ps: yes, I have thought of how to apply this in the no-H-mode proposal.
Assuming the 2-bits definition of mflags.VM from this email, the
extension could be:
- VM[3:2] becomes a new field HPVM, defining the hpptbr format
- VM[4] is HVM: 0 for two-level translation with 32-bit page-table
entries, 1 for 64-bit page-table entries.
- both mstatus.HPVM and mstatus.HVM are visible in hstatus
- both HRET and hypervisor traps swap mstatus.SVM with mstatus.HPVM

With the separate MVM/SVM from the previous attempt, you'd need a sixth
bit for HVM.

[Tommy Thorn]

Glad to see more debate about the virtualization. I’d hate to discover
design flaws after silicon has started shipping.

> If stacking segmentation with paging is unnecessary, why even make
> segmentation an M-mode concept, and paging an S-mode concept? Both
> could be simply S-mode concepts, that naturally move up to M-mode if
> S-mode doesn't exist.

I think the idea is to offer the segmentation options for core targeting
the embedded space and thus would not support S-mode. I don’t think
you would implement segmentation if you had paging.

I’m not convinced the priv spec needs to include it. I haven’t seen any documented demand for segmentation and I suspect anyone wanting to include it would probably have their own incompatible variation. (In contrast, having a standard platform for major OSes is obviously important).

Tommy

[Stefan O'Rear]

On Mon, Sep 19, 2016 at 10:55 AM, Andrew Waterman <and...@sifive.com> wrote:
> Thanks for taking the time to think about these issues.
>
> On Mon, Sep 19, 2016 at 8:05 AM, Paolo Bonzini <bon...@gnu.org> wrote:
>> One of the aspects of the RISC-V privileged architecture that puzzled me
>> the most is that VM is not part of sstatus. Yet, there's no way to set
>> it via SBI, so the OS must know how to deal with whatever page table
>> format has been set by M-mode code.
>
> Our expectation is that the loader sets the VM field for the OS, and
> then it would remain constant. A field in the ELF header could carry
> this information.

I'm concerned by the implication that I'd need a separately
compiled/linked "Sv48 kernel" for running jobs that need to mmap()
more than 256GB of files (lower half of a Sv39 address space). Is
there any way we can support a unified kernel that adapts to the
hardware capabilities and/or the amount of address space required at
runtime?

Side note, giving the kernel the ability to turn paging on and off
would greatly simplify the boot protocol I'm trying to put together,
since tracking the memory allocated to pre-boot page tables is
actually rather fiddly.

-s

[Paolo Bonzini]

On 19/09/2016 23:53, Tommy Thorn wrote:
> > If stacking segmentation with paging is unnecessary, why even make
> > segmentation an M-mode concept, and paging an S-mode concept? Both
> > could be simply S-mode concepts, that naturally move up to M-mode if
> > S-mode doesn't exist.
>
> I think the idea is to offer the segmentation options for core targeting
> the embedded space and thus would not support S-mode. I don’t think
> you would implement segmentation if you had paging.

It may make sense to have both though.

For example you could envision a RTOS that also acts as a hypervisor;
realtime tasks would run in U-mode under segmentation (no pages to worry
about for WCET analysis!), whereas non-realtime tasks run under a
full-blown Linux guest using two-level address translation...

Paolo

[Jacob Bachmeyer]

Andrew Waterman wrote:
> Thanks for taking the time to think about these issues.
>
> On Mon, Sep 19, 2016 at 8:05 AM, Paolo Bonzini <bon...@gnu.org> wrote:
>
>> One of the aspects of the RISC-V privileged architecture that puzzled me
>> the most is that VM is not part of sstatus. Yet, there's no way to set
>> it via SBI, so the OS must know how to deal with whatever page table
>> format has been set by M-mode code.
>>
>
> Our expectation is that the loader sets the VM field for the OS, and
> then it would remain constant. A field in the ELF header could carry
> this information.
>

A good design until virtualization is considered--hypervisor guests may
need different VM modes, at least at the vCPU level.

> This seems like a reasonable design to me, but I'm not yet convinced
> supervisor software needs direct control over the page table depth
> (and, if it does, whether an SBI call would suffice).
>

Direct control without an SBI call could enable different U-mode
processes to use different page table depths. I made a proposal along
these lines back in the "RISC-V Privileged Architecure Proposal v1.9"
thread (message-id <57B4E7D8...@gmail.com>) with the biggest
difference being that I did not think of breaking up the VM field.

> Does exposing this option directly to the OS complicate hypervisor
> implementation at all?
>

I will defer to Paolo Bonzini on that, although translation from
user/supervisor virtual addresses to supervisor physical addresses
should be handled by hardware in a manner that is transparent to a
hypervisor.


I suggest a terminology change from my previous proposal: consider
looking at page table depth as "paging height" instead of "depth". A
physical 4KiB page is at height-0, a "megapage" or a page table
describing 4KiB pages is at height-1, a "gigapage" or page table
describing height-1 entries is at height-2, and so on. The paging
height is the LEVELS value in sec. 4.5.2 and must be known before
address translation can begin. An address space in RISC-V is determined
by a paging height and a root physical page number.


-- Jacob

[Andrew Waterman]

This use case is certainly plausible, but configurable physical memory
protection may suffice, rather than using the base & bounds
translation scheme. The RTOS might have to be linked
position-independently, but that is not costly on RISC-V.

>
> Paolo

[Andrew Waterman]

We need to think through the implications, but moving SVSZ out of
mstatus.VM and into SPTBR does seem sensible.

Minor detail, but I think the entire SPTBR write should have no effect
if you attempt to set an unsupported SVSZ, so that you don't e.g. swap
in an Sv48 page table if the system only supports Sv39. This should
make it simpler to implement an OS that can cope with either page
table format.

On Mon, Sep 19, 2016 at 8:05 AM, Paolo Bonzini <bon...@gnu.org> wrote:

[Jacob Bachmeyer]

Andrew Waterman wrote:
> We need to think through the implications, but moving SVSZ out of
> mstatus.VM and into SPTBR does seem sensible.
>
> Minor detail, but I think the entire SPTBR write should have no effect
> if you attempt to set an unsupported SVSZ, so that you don't e.g. swap
> in an Sv48 page table if the system only supports Sv39. This should
> make it simpler to implement an OS that can cope with either page
> table format.
>

Not just simpler--ignoring an invalid write to sptbr entirely is really
the only way. If the root of an Sv48 page table is selected in sptbr,
but the system only supports Sv39 and will therefore interpret the Sv48
root page as an Sv39 root page, every single access will fault. Unless
the monitor can somehow magically recover from the ensuing mess, the
system has just crashed.

Also, combining this movement of SVSZ into SPTBR with my (just now)
proposal ("Standard multi-width execution") for controlling XLEN in
RV64/RV128 systems with RV32 support would enable reducing all of the
Sv* modes to a single Spage mode for supervisor-controlled paging,
saving mstatus.VM encoding space for future developments.

How long do we want RISC-V to last? I favor "the foreseeable future" as
an expected lifespan. :)

-- Jacob

[Paolo Bonzini]

On 22/09/2016 02:08, Andrew Waterman wrote:
> On Mon, Sep 19, 2016 at 3:01 PM, Paolo Bonzini <bon...@gnu.org> wrote:
>>
>>
>> On 19/09/2016 23:53, Tommy Thorn wrote:
>>>> If stacking segmentation with paging is unnecessary, why even make
>>>> segmentation an M-mode concept, and paging an S-mode concept? Both
>>>> could be simply S-mode concepts, that naturally move up to M-mode if
>>>> S-mode doesn't exist.
>>>
>>> I think the idea is to offer the segmentation options for core targeting
>>> the embedded space and thus would not support S-mode. I don’t think
>>> you would implement segmentation if you had paging.
>>
>> It may make sense to have both though.
>>
>> For example you could envision a RTOS that also acts as a hypervisor;
>> realtime tasks would run in U-mode under segmentation (no pages to worry
>> about for WCET analysis!), whereas non-realtime tasks run under a
>> full-blown Linux guest using two-level address translation...
>
> This use case is certainly plausible, but configurable physical memory
> protection may suffice,

Wouldn't that require the RTOS to run in M-mode? The idea is that it
would run in H- (or S-mode with hypervisor extensions).

Paolo

[Andrew Waterman]

On Thu, Sep 22, 2016 at 12:32 AM, Paolo Bonzini <bon...@gnu.org> wrote:
>
>
> On 22/09/2016 02:08, Andrew Waterman wrote:
>> On Mon, Sep 19, 2016 at 3:01 PM, Paolo Bonzini <bon...@gnu.org> wrote:
>>>
>>>
>>> On 19/09/2016 23:53, Tommy Thorn wrote:
>>>>> If stacking segmentation with paging is unnecessary, why even make
>>>>> segmentation an M-mode concept, and paging an S-mode concept? Both
>>>>> could be simply S-mode concepts, that naturally move up to M-mode if
>>>>> S-mode doesn't exist.
>>>>
>>>> I think the idea is to offer the segmentation options for core targeting
>>>> the embedded space and thus would not support S-mode. I don’t think
>>>> you would implement segmentation if you had paging.
>>>
>>> It may make sense to have both though.
>>>
>>> For example you could envision a RTOS that also acts as a hypervisor;
>>> realtime tasks would run in U-mode under segmentation (no pages to worry
>>> about for WCET analysis!), whereas non-realtime tasks run under a
>>> full-blown Linux guest using two-level address translation...
>>
>> This use case is certainly plausible, but configurable physical memory
>> protection may suffice,
>
> Wouldn't that require the RTOS to run in M-mode? The idea is that it
> would run in H- (or S-mode with hypervisor extensions).

I was imagining that it run in S[/H]-mode with mstatus.VM=Mbb.

[Andrew Waterman]

On Thu, Sep 22, 2016 at 12:56 AM, Andrew Waterman <and...@sifive.com> wrote:
> On Thu, Sep 22, 2016 at 12:32 AM, Paolo Bonzini <bon...@gnu.org> wrote:
>>
>>
>> On 22/09/2016 02:08, Andrew Waterman wrote:
>>> On Mon, Sep 19, 2016 at 3:01 PM, Paolo Bonzini <bon...@gnu.org> wrote:
>>>>
>>>>
>>>> On 19/09/2016 23:53, Tommy Thorn wrote:
>>>>>> If stacking segmentation with paging is unnecessary, why even make
>>>>>> segmentation an M-mode concept, and paging an S-mode concept? Both
>>>>>> could be simply S-mode concepts, that naturally move up to M-mode if
>>>>>> S-mode doesn't exist.
>>>>>
>>>>> I think the idea is to offer the segmentation options for core targeting
>>>>> the embedded space and thus would not support S-mode. I don’t think
>>>>> you would implement segmentation if you had paging.
>>>>
>>>> It may make sense to have both though.
>>>>
>>>> For example you could envision a RTOS that also acts as a hypervisor;
>>>> realtime tasks would run in U-mode under segmentation (no pages to worry
>>>> about for WCET analysis!), whereas non-realtime tasks run under a
>>>> full-blown Linux guest using two-level address translation...
>>>
>>> This use case is certainly plausible, but configurable physical memory
>>> protection may suffice,
>>
>> Wouldn't that require the RTOS to run in M-mode? The idea is that it
>> would run in H- (or S-mode with hypervisor extensions).
>
> I was imagining that it run in S[/H]-mode with mstatus.VM=Mbb.

Sorry, I meant Mbare.

[Paolo Bonzini]

On 22/09/2016 09:57, Andrew Waterman wrote:
>>>> For example you could envision a RTOS that also acts as a hypervisor;
>>>> realtime tasks would run in U-mode under segmentation (no pages to worry
>>>> about for WCET analysis!), whereas non-realtime tasks run under a
>>>> full-blown Linux guest using two-level address translation...
>>>>
>>>> This use case is certainly plausible, but configurable physical memory
>>>> protection may suffice,
>>>
>>> Wouldn't that require the RTOS to run in M-mode? The idea is that it
>>> would run in H- (or S-mode with hypervisor extensions).
>>
>> I was imagining that it run in S[/H]-mode with mstatus.VM=Mbb.
>
> Sorry, I meant Mbare.

Yes, that's possible but it depends on the interfaces that S/H-modes
have to enable/disable paging when running non-real-time tasks (and on
their overhead).

In general, I like the idea that removing privilege levels is orthogonal
to removing features. Imagine a processor where that you don't have
S-mode, but you do have some S-mode CSRs (discoverable via e.g. mstatus
or WARL) which would have an effect on U-mode. Since M-mode has access
to S-mode CSRs, this actually fits the design very well. In this way,
it makes sense to make segmentation and paging a sstatus field rather
than restricting it to mstatus. It's always possible to configure
things out of the processor and only support bare or base/bound addressing.

Taking this somewhat to the extreme, the hypervisor proposal is designed
so that the M-mode monitor could configure medeleg/mideleg to get all
the traps, and setup mstatus before MRET so that U-mode runs with
two-level paging. You only need the s* and h* CSRs to be available for
this to work, you don't need the processor to _actually_ support S-mode
or hypervisor traps HRET.

It doesn't take any effort to support this admittedly weird case---it
just works.

Paolo

[Andrew Waterman]

It does just work, but essentially all of the HW cost of implementing
S-mode is in the CSRs (and the features they imply); supporting the
privilege mode itself is, by comparison, free. So this is a false
economy, as it increases ISA fragmentation with basically no upside.

>
> Paolo

[Paolo Bonzini]

On 22/09/2016 20:35, Andrew Waterman wrote:
> > It doesn't take any effort to support this admittedly weird case---it
> > just works.
>
> It does just work, but essentially all of the HW cost of implementing
> S-mode is in the CSRs (and the features they imply); supporting the
> privilege mode itself is, by comparison, free. So this is a false
> economy, as it increases ISA fragmentation with basically no upside.

It only adds feature for M-mode, which is anyway going to be fragmented
because PMA/PMP and similar is not part of the spec (and you've brought
up PMA/PMP several times as workarounds in this discussion).

So one could also say that it adds flexibility with no practical
downside, and that---because M-mode is non-portable
anyway---implementors are free to do it anyway. No one would be any
wiser, except that they'd all do things in slightly different and
possibly buggy ways...

On the other hand, if you're worried about architecture fragmentation,
by the same reasoning (non-portability, etc.) there are clear advantages
in making M-mode features available in S-mode.

Paolo