1. Tech-Privileged
  2. Topics

[RISC-V] [tech-virt-mem] Help needed on physical address issues

mark
 

+tech-privileged 

The virt-mem list is quiescent and will go away shortly. Please send questions like this to the governing committee (priv). I have plus'ed them in.

Mark

On Tue, Aug 9, 2022 at 3:24 AM Ke Chai <ck.rickytino@...> wrote:
To whom it may concern,

Hello! I am currently working on a RV64 CPU featuring Sv48 and Sv39, and came up with several questions that none of the existing documents have clearly specified: 

1. The physical address width in my RV64 implementation is 50 bits. If a 56-bit address is generated (e.g. from a leaf PTE's PPN concatenates an address offset, or from a physical address translated directly from a virtual address under M mode) with non-zero at the high bits (i.e. bits 55-50), should I just ignore the high bits, or report an access fault exception (assuming this is recognized as an vacant address space during a PMA check)?

2. Is there any way the M-mode software can know how many physical address bits are implemented on this implementation?

3. I saw a sentence on the RISC-V privileged architecture document at the end of section 4.3.2:
"The algorithm does not admit the possibility of ignoring high-order PPN bits for implementations with narrower physical addresses". What does "does not admit the possibility" supposed to mean? What action would be taken by hardware if the high-order PPN bits are not zero?

Really looking forward to someone who can give me some clarification on this! 

Thank you so much,
Ricky Chai
Greg Favor
 

On Tue, Aug 9, 2022 at 7:07 AM mark <markhimelstein@...> wrote:
On Tue, Aug 9, 2022 at 3:24 AM Ke Chai <ck.rickytino@...> wrote:
To whom it may concern,

Hello! I am currently working on a RV64 CPU featuring Sv48 and Sv39, and came up with several questions that none of the existing documents have clearly specified: 

1. The physical address width in my RV64 implementation is 50 bits. If a 56-bit address is generated (e.g. from a leaf PTE's PPN concatenates an address offset, or from a physical address translated directly from a virtual address under M mode) with non-zero at the high bits (i.e. bits 55-50), should I just ignore the high bits, or report an access fault exception (assuming this is recognized as an vacant address space during a PMA check)?

2. Is there any way the M-mode software can know how many physical address bits are implemented on this implementation?

3. I saw a sentence on the RISC-V privileged architecture document at the end of section 4.3.2:
"The algorithm does not admit the possibility of ignoring high-order PPN bits for implementations with narrower physical addresses". What does "does not admit the possibility" supposed to mean? What action would be taken by hardware if the high-order PPN bits are not zero?

The way to view this matter is that PA's are full 56-bit zero-extended values.  It is up to PMAs to, for example, mark the top six bits of PA space as a big 'vacant' region that results in an Access Fault on all attempted accesses with PA[55:50] != 'b000000.  That 'vacant' PMA region can of course be a "fixed" PMA region that only requires the address decode logic gates to implement.

The new (in development) RISC-V Unified Discovery mechanism will support low-level discovery of exactly things like this (and many other things).  If you're running, for example, a Linux OS, then higher-level (post OS boot) discovery would typically be provided via Device Tree of ACPI tables.

Greg
Ke Chai
 

Hi Greg, 

Thanks for replying! I am sure your answer about the RISC-V Unified Discovery perfectly answered my question 2. 

In my current implementation, bit [55:50] is simply ignored, which means my PMA checker receives bits [49:0] as its input. I am asking for help because I suspect that I am doing the wrong thing. As I understand your answer, this is a possible solution, but what I really want to know is whether both measures (ignore high-order bits versus reporting PMA vacant region) are acceptable or either one is the only correct answer. The RISC-V ISA documents are really giving me little clue about this. 

Thanks again,
Ricky Chai


Greg Favor <gfavor@...> 于2022年8月10日周三 00:09写道：

On Tue, Aug 9, 2022 at 7:07 AM mark <markhimelstein@...> wrote:
On Tue, Aug 9, 2022 at 3:24 AM Ke Chai <ck.rickytino@...> wrote:
To whom it may concern,

Hello! I am currently working on a RV64 CPU featuring Sv48 and Sv39, and came up with several questions that none of the existing documents have clearly specified: 

1. The physical address width in my RV64 implementation is 50 bits. If a 56-bit address is generated (e.g. from a leaf PTE's PPN concatenates an address offset, or from a physical address translated directly from a virtual address under M mode) with non-zero at the high bits (i.e. bits 55-50), should I just ignore the high bits, or report an access fault exception (assuming this is recognized as an vacant address space during a PMA check)?

2. Is there any way the M-mode software can know how many physical address bits are implemented on this implementation?

3. I saw a sentence on the RISC-V privileged architecture document at the end of section 4.3.2:
"The algorithm does not admit the possibility of ignoring high-order PPN bits for implementations with narrower physical addresses". What does "does not admit the possibility" supposed to mean? What action would be taken by hardware if the high-order PPN bits are not zero?

The way to view this matter is that PA's are full 56-bit zero-extended values.  It is up to PMAs to, for example, mark the top six bits of PA space as a big 'vacant' region that results in an Access Fault on all attempted accesses with PA[55:50] != 'b000000.  That 'vacant' PMA region can of course be a "fixed" PMA region that only requires the address decode logic gates to implement.

The new (in development) RISC-V Unified Discovery mechanism will support low-level discovery of exactly things like this (and many other things).  If you're running, for example, a Linux OS, then higher-level (post OS boot) discovery would typically be provided via Device Tree of ACPI tables.

Greg
Scott Johnson
 

Ignoring the high bits is not acceptable. It must take an access fault.

I agree the specs do not make this entirely clear.
Allen Baum
 

Note that the (unratified)  pointer masking extension would permit upper bits to be ignored (but not "simply" be ignored).


On Wed, Aug 10, 2022 at 5:26 AM Scott Johnson <scott.johnson@...> wrote:
Ignoring the high bits is not acceptable. It must take an access fault.

I agree the specs do not make this entirely clear.

Ved Shanbhogue
 

I think the pointer-masking extension would ignore upper bits in a virtual address - but only for the canonicality check. 
Of course, when virtual memory systems are not enabled then they are the same but I do not recall if pointer-masking
is applicable when virtual memory systems are not enabled.
regards
ved


On Wed, Aug 10, 2022 at 9:03 AM Allen Baum <allen.baum@...> wrote:
Note that the (unratified)  pointer masking extension would permit upper bits to be ignored (but not "simply" be ignored).


On Wed, Aug 10, 2022 at 5:26 AM Scott Johnson <scott.johnson@...> wrote:
Ignoring the high bits is not acceptable. It must take an access fault.

I agree the specs do not make this entirely clear.

Allen Baum
 

It works on virtual addresses, and when MMU is disabled, virtual=physical.  As I said, not "simply" ignored..

On Wed, Aug 10, 2022 at 7:07 AM Ved Shanbhogue <ved@...> wrote:
I think the pointer-masking extension would ignore upper bits in a virtual address - but only for the canonicality check. 
Of course, when virtual memory systems are not enabled then they are the same but I do not recall if pointer-masking
is applicable when virtual memory systems are not enabled.
regards
ved

On Wed, Aug 10, 2022 at 9:03 AM Allen Baum <allen.baum@...> wrote:
Note that the (unratified)  pointer masking extension would permit upper bits to be ignored (but not "simply" be ignored).


On Wed, Aug 10, 2022 at 5:26 AM Scott Johnson <scott.johnson@...> wrote:
Ignoring the high bits is not acceptable. It must take an access fault.

I agree the specs do not make this entirely clear.

Ke Chai
 

Thanks Scott, Allen and Ved for your clarification!
Still one little question: What happens when MMU is disabled (VA=PA) and bit [63:56] is not zero? Still report Access Fault? Or are we assuming the full-PA width is 64 or 56?
Btw I would appreciate it if someone could add what we've discuss above, about PA width, into the privileged spec :) 
Allen Baum
 

My understanding is that the physical address size is implementation dependent. 
Iif any bit above that is set, it should report an access fault.
The ACTs don't specifically test for that now, but they will (where the implementer defines the size in its riscv-config YAML file.
It should also be defined in the config-struct encoding at some point.

On Wed, Aug 10, 2022 at 8:05 PM Ke Chai <ck.rickytino@...> wrote:
Thanks Scott, Allen and Ved for your clarification!
Still one little question: What happens when MMU is disabled (VA=PA) and bit [63:56] is not zero? Still report Access Fault? Or are we assuming the full-PA width is 64 or 56?
Btw I would appreciate it if someone could add what we've discuss above, about PA width, into the privileged spec :) 

Greg Favor
 

Still one little question: What happens when MMU is disabled (VA=PA) and bit [63:56] is not zero? Still report Access Fault? Or are we assuming the full-PA width is 64 or 56?

My earlier statement about PAs conceptually or architecturally being viewed as zero-extended values makes them agnostic to implemented PA size.  In general, and irrespective of where a PA comes from (e.g. from M-mode, Bare translation mode, or a translated mode), one conceptually has a 64-bit PA.  

If a PA is the result of translation, then one has a 56-bit zero-extended PA, i.e. the translated 56-bit PA from the leaf PTE is zero-extended up to 64 bits.  Also, no matter what, the entire PPN field is used to create the final overall PA.

If a PA is the result of calculation by a register instruction, then one has a full 64-bit PA (assuming RV64).  The full 64-bit calculated value becomes the PA.

At the end of the day one always has a 64-bit PA that is then checked by PMAs.  So if a system only "implements" an N-bit PA space, then all 64-N msb's of a PA must be zeroes - as enforced by having a "vacant" PMA region that covers the 64-N bits of PA space and causes an Access Fault.  Practically speaking this allows address-specific datapaths to only be 64-N bits wide since one can check for all high PA bits being zeroes right away (and not carry them forward).
 
Ke Chai
 

Thanks again to everyone! These answers make sense to me. 
Allen Baum
 

The ACTs will test that bits above b38 match b38 if SV39 is enabled
Likewise for SV48 and SV 57.
There is no SV64 yet, so any VA bits above b56 that don't match b56 are expected to always trap.

If a PMA doesn't do that, it will fail ACTs 

Greg: are you saying the canonicity boundary of VAs is always bit 56? Because that's not my reading.
For PAs, on the other hand, the PA width is not an architectural constant, its an inplmentation choice.
ACTs expect the DUT config YAML to specify how wide the PA is, and any non-zero bits above that are expected to trap.

@Bill.McSpadden: this is another thing that Sail needs to be aware of (it's in my list of unnamed architectural options).



On Thu, Aug 11, 2022 at 8:30 PM Ke Chai <ck.rickytino@...> wrote:
Thanks again to everyone! These answers make sense to me. 

1 - 12 of 12