1. Tech-Unixplatformspec
  2. Topics

[RISC-V] [tech-virt-mem] [RISC-V] [tech-unixplatformspec] Two alternatives for architecture extension to specify address/page-based memory types

Allen Baum
 

I thought the major issue with #1 was how to keep PTE based attributes isynchronized with M-code on the same hart running in bare mode that has no PTE bits to look at and might access without knowledge of the code (e.g. speculatively). Turning off speculation in M-code might fix that at some cost (and we’d need to architect that as well)

-Allen

On Sep 7, 2020, at 8:17 PM, Anup Patel <anup.patel@...> wrote:

Hi Greg,

 

I am inclined towards Option#1 provided the new PTE format is compatible with existing PTE format for Sv32/Sv39/Sv48.

 

Is the Option#1 documented somewhere ?

 

Regards,

Anup

 

From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Greg Favor
Sent: 08 September 2020 03:58
To: tech-unixplatformspec@...; software@...
Cc: tech-virt-mem@...; Greg Favor <gfavor@...>
Subject: [RISC-V] [tech-unixplatformspec] Two alternatives for architecture extension to specify address/page-based memory types

 

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).

 

Greg

 

1 - 1 of 1