OS_PlatformFeatures 0 OS flag allocation

Hiya,

The allocations service doesn’t handle a bunch of things, so I’m using this forum as a notification that I’m intending to use a bit in OS_PlatformFeatures 0 to indicate one of the OS capabilities.

https://www.riscosopen.org/wiki/documentation/show/OS_PlatformFeatures%200%20Flags

… states that bits up to 21 are in use, and that (specifically) bit 21 is allocated to ‘physical pages are large’.

The new bit I am going to add would therefore be bit 22, defined as:

No physical pages are available to the user, and manual page remapping is not possible. Interfaces such as `OS_ReadMemMapEntries` and friends, the dynamic area physical page request interfaces, and any MMU operations are not supported by the OS.

OSPlatformFeaturesCode_NoPhysicalPages = (1<<22)    # Physical pages do not exist, and cannot be accessed through
                                                    # OS_ReadMemMapEntries and friends. No dynamic area physical pages
                                                    # may be used.

This bit will be set by RISC OS Pyromaniac. At present the only way to discover that physical memory does not exist is to try to access the page tables. A flag in interface gives a mechanism by which this can be found by introspection.

I know this isn’t a code feature, but OS_PlatformFeatures has been used to incude other CPU features which are related to the MMU, so it seems appropriate to include it here.

using this forum as a notification

I believe the intention of this forum is for discussion of proposed changes, where people knowledgeable on the area in question can peer review proposed changes to sanity check and discuss any knock on effects.

the only way to discover that physical memory does not exist is to try to access the page tables

I’m struggling to understand how there can be no physical pages? Could you explain under what condition this could occur? How does the OS even run if there’s no physical or logical address space?

I’m struggling to understand how there can be no physical pages? Could you explain under what condition this could occur? How does the OS even run if there’s no physical or logical address space?

First, let me correct your statement that there is no logical address space. This feature flag description mentions nothing about logical address space, and indeed logical address space is exactly as you would expect. This only talks about the existance of physical pages being accessible.

There are two cases where you want this to be the case:

1. Where the system doesn’t want to allow you access to the physical pages. This is the most common and probably the most desireable case for even native systems. In this case, the Kernel is in complete control of the system. Nobody can hide memory, it has an understanding of everything that goes on and nobody can poke around behind its back. Since the page tables are not a features that you would normally allow access to on pretty much any serious system, this is would make RISC OS more like the norm on other system.

2. Where the system doesn’t have a concept of physical pages, or where the concept is so alien that it cannot be exposed using the existing API. This is the case for Pyromaniac which doesn’t use the MMU, or L1 or L2 page tables. Memory is mapped in from the host. Within RISC OS you have no control whatsoever about what pages those are or where they appear from.

The former of these cases is entirely desireable on a native ARM system, as it provides the Kernel a greater degree of control over the system’s operation, improving the reliability and stability of the system. The latter case is already in use within RISC OS Pyromaniac, as its low level memory operations are entirely different to those used by RISC OS Classic.

states that bits up to 21 are in use, and that (specifically) bit 21 is allocated to ‘physical pages are large’.

Physical addresses are large. Page size is unrelated.

The new bit I am going to add would therefore be bit 22, defined as …

That sounds fine to me.

The former of these cases is entirely desireable on a native ARM system, as it provides the Kernel a greater degree of control over the system’s operation, improving the reliability and stability of the system.

There are some cases where giving programs limited control over the mapping of their own memory is desirable, e.g. using a PMP DA to provide access to more RAM than can fit in logical address space. Possibly there are also be some situations where allowing programs to mess with the permissions of its memory would be desirable (e.g. to detect which pages are being written to, for a system that needs to track modified memory).

For Pyromaniac I’d imagine that these cases would be hard to support (you’re limited by the APIs provided by the host OS), but for a “hardened” version of RISC OS I think we’d want to be able to retain that sort of functionality.

Physical addresses are large. Page size is unrelated.

Doh, yeah, I mis-paraphrased that badly.

For Pyromaniac I’d imagine that these cases would be hard to support (you’re limited by the APIs provided by the host OS), but for a “hardened” version of RISC OS I think we’d want to be able to retain that sort of functionality.

With the current implementation, Unicorn (not the host OS) doesn’t offer easy simple ways of doing that – I can emulate a lot of them over the top of Unicorn, but it’s just not worth the effort. I did consider using the memory pool style of working for pages but that too is just not worthwhile – the amount of gain in doing so is so small in mirroring the legacy mechanism by with RISC OS allocates pages that I didn’t see any reason to keep it on.