Two alternatives for architecture extension to specify address/page-based memory types

Greg Favor

To all the system software people on the tech-unixplatformspec and software email lists:

The tech-virt-mem Task Group is considering two alternative approaches for specifying address/page-based attributes - which are analogous to "memory types" in x86 ( WB/WC/UC) and ARMv8 (Normal cacheable, Normal noncacheable, Device).  This email attempts to get further feedback from system software / device driver people as to the practical useability, pros and cons, and preference for the two approaches (at a gross first-order level, so I won't belabor the details of the two approaches).  Also note that both approaches would override the default attributes that come from RISC-V PMAs - which are very roughly analogous to x86 MTRRs.

Option #1 - VA/Page-Based Attributes
This approach utilizes 2-3 bits in page table entries to specify a memory type for the page (roughly corresponding to the above x86 and ARMv8 memory types).  This approach is similar to the approach supported by x86 and ARMv8, and presumably would directly mesh with existing Linux support for this type of approach.

Option #2 - Physical Address-Based Attributes
This approach uses the top 2-3 bits of a 64-bit PA (physical address) to specify a memory type for that address value.  This approach applies equally whether MMU address translation is On or Off (where Off corresponds to RISC-V M-mode and Bare translation modes).  When translation is On, these bits likely (like above) would occupy extra bits in page table entries.  When translation is Off, the high bits of the 64-bit address calculation result are used.

While there are some small pros and cons with these two approaches, I'll hold off from coloring people's feedback. (and thanks in advance for that feedback).


Join { to automatically receive all group messages.