(I’m new to this email alias so I may be missing the context of past discussions. I apologize up front if I’m rehashing past discussions.)

 

My preference would be Option #1 since I’m familiar with implementing a scheme with PTE based CCA with Virtualization which has support in Linux and has been used by customers. So it works.

 

For the RISC-V implementation, we contemplate adding PMA CCA and Idempotency control to M-mode. This should deal with the issue Allen mentions.

 

Now if PTE CCAs are added to S-mode page tables, the problem of nesting of CCAs occurs between M-mode and S-mode. A scheme needs to be implemented but this is a problem with both Option 1 and 2. Handling for such nesting can be easily architected.

 

Has the impact of H-extension on CCAs been thought through?

 

1. VS-mode Guest Supervisor/User generates CCA, possibly HS-mode Hypervisor and then M-mode pma. // Possibly 3 levels of CCA nesting!
2. HS-mode User generates CCA, and then M-mode pma.

 

To limit the effective CCA to two levels of interpretation, would Hypervisor Guest Physical to System Physical translation NOT generate CCAs. (#1)

CCAs should still be generated for HS-mode user. (#2)

 

Is this the plan?

 

For Option 2, using the upper bits of PA for CCA sounds like the scheme for MIPS, but MIPS limits this to kernel unmapped space. For mapped addresses it is not clear what the role of the OS would be in allocating such CCA to physical addresses. Has the OS/Hypervisor impact been thought through? Since OS is already allocating VA->PA translations on page boundaries, maybe it just makes sense to do the same for CCA.

 

Sanjay

 

From: <tech-virt-mem@...> on behalf of "Allen Baum via lists.riscv.org" <allen.baum=esperantotech.com@...>
Reply-To: "tech-virt-mem@..." <tech-virt-mem@...>, "allen.baum@..." <allen.baum@...>
Date: Monday, September 7, 2020 at 8:32 PM
To: "tech-virt-mem@..." <tech-virt-mem@...>, "anup.patel@..." <anup.patel@...>
Cc: Greg Favor <gfavor@...>, "tech-unixplatformspec@..." <tech-unixplatformspec@...>, "software@..." <software@...>
Subject: [EXTERNAL]Re: [RISC-V] [tech-virt-mem] [RISC-V] [tech-unixplatformspec] Two alternatives for architecture extension to specify address/page-based memory types

 

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