[EXTERNAL]Re: [RISC-V] [tech-virt-mem] [RISC-V] [tech-unixplatformspec] Two alternatives for architecture extension to specify address/page-based memory types
Sanjay Patel <spatel@...>
(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?
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.
From: <tech-virt-mem@...> on behalf of "Allen Baum via lists.riscv.org" <allen.baum=esperantotech.com@...>
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)
toggle quoted message Show quoted text
Regarding your virtualization question: Yes, this has been considered. Either option would have attribute overrides coming from both stages of address translation page tables - that would be combined together in a suitable way. This is some of the detail I left out of the question I posed since the issue is, in fact, largely orthogonal to the two options. (x86 and ARMv8 have their equivalent "combining" definitions.)
On Tue, Sep 8, 2020 at 10:30 AM Sanjay Patel <spatel@...> wrote:
|1 - 2 of 2|