SV32 and 34 bit address


Gracy Ge
 

I reused a topic title under https://github.com/riscv/riscv-isa-manual/issues/131
And also I attached some comments in section 4.4.1 of privileged spec those confused me so much,

A. Sv39 implementations support a 39-bit virtual address space, divided into 4 KiB pages. An Sv39
address is partitioned as shown in Figure 4.18. Instruction fetch addresses and load and store
effective addresses, which are 64 bits, must have bits 63–39 all equal to bit 38, or else a page-fault
exception will occur.

B. When mapping between narrower and wider addresses, RISC-V usually zero-extends a narrower
address to a wider size. The mapping between 64-bit virtual addresses and the 39-bit usable
address space of Sv39 is not based on zero-extension but instead follows an entrenched convention
that allows an OS to use one or a few of the most-significant bits of a full-size (64-bit) virtual
address to quickly distinguish user and supervisor address regions.

I have similar issues on SV32 and SV39. 
1.  In SV32, access to only the low 4Gb (i.e. the top 12Gb are not accessible) in bare mode or machine mode.
     Can I understand this is explicitly stated from #B(zero extends) in section4 4.4.1? 
2.  How to understand the usable address space in SV39? Shall OS make sure the address zero extend the higher bits or keep it [38] extended? IMO, statement in #A and #B is conflicted. Forgave me if I misunderstood it. 
3.  In sv39, what is the valid address space in bare mode or Machine mode? Is it maximum 64 bit wide? I know it is not a real case, just to make sure the ideal limitation here. 
4.  Last question in SV32, OS can utilize the MAPPING scheme of SV32 and get physical address used up to 16G. However currently gcc compiler for 32 bit system only have 4G memory usage, How can I compile a testcase and link them to LMA at upper 12G memory space? 

Best Regards, 
Gracy


Daniel Lustig
 

Hi Gracy,

When satp.mode is not bare, virtual addresses must be sign-extended
to fill XLEN. When the physical address generated in any mode is
smaller than the implementation's physical address space, the physical
address is zero-extended. That's the difference.

In Rv32 bare mode, 32b virtual addresses are treated as 32b physical
addresses. If a machine has more than 32b of physical address space
(as will be common, since Sv32 supports 34b PAs), then the 32b bare VA
will be zero-extended to form the PA. All 34b are directly accessible
when in Sv32 mode.

In Sv39, each VA must have bits 63-39 equal to bit 38, as described.
Sv39 translation will produce a 56b PA. If the implementation has more
than 56 physical address bits, that 56b PA will be zero-extended to
the right number of bits.

Does that make sense? Hope that helps,
Dan

On 2/22/2021 3:28 AM, Gracy Ge wrote:
I reused a topic title under https://github.com/riscv/riscv-isa-manual/issues/131
And also I attached some comments in section 4.4.1 of privileged spec those confused me so much,

*A*. Sv39 implementations support a 39-bit virtual address space, divided into 4 KiB pages. An Sv39
address is partitioned as shown in Figure 4.18. Instruction fetch addresses and load and store
effective addresses, which are *64 bits* , must have bits *63–39 all equal to bit 38* , or else a page-fault
exception will occur.

*B*. When mapping between narrower and wider addresses, RISC-V usually *zero-extends* a narrower
address to a wider size. The mapping between 64-bit virtual addresses and the 39-bit usable
address space of Sv39 is not based on zero-extension but instead follows an entrenched convention
that allows an OS to use one or a few of the most-significant bits of a full-size (64-bit) virtual
address to quickly distinguish user and supervisor address regions.

I have similar issues on SV32 and SV39.
1. In SV32, access to only the low 4Gb (i.e. the top 12Gb are not accessible) in bare mode or machine mode.
Can I understand this is explicitly stated from *#B* ( *zero extends* ) in section4 4.4.1?
2.  How to understand the usable address space in SV39? Shall OS make sure the address zero extend the higher bits or keep it [38] extended? IMO, statement in # *A* and # *B* is conflicted. Forgave me if I misunderstood it.
3.  In sv39, what is the valid address space in bare mode or Machine mode? Is it maximum 64 bit wide? I know it is not a real case, just to make sure the ideal limitation here.
4.  Last question in SV32, OS can utilize the MAPPING scheme of SV32 and get physical address used up to 16G. However currently gcc compiler for 32 bit system only have 4G memory usage, How can I compile a testcase and link them to LMA at upper 12G memory space?

Best Regards,
Gracy


Richard Trauben
 

it makes sense but in what way does this make us more secure?

On Feb 22, 2021, at 7:53 AM, Daniel Lustig <dlustig@...> wrote:

Hi Gracy,

When satp.mode is not bare, virtual addresses must be sign-extended
to fill XLEN. When the physical address generated in any mode is
smaller than the implementation's physical address space, the physical
address is zero-extended. That's the difference.

In Rv32 bare mode, 32b virtual addresses are treated as 32b physical
addresses. If a machine has more than 32b of physical address space
(as will be common, since Sv32 supports 34b PAs), then the 32b bare VA
will be zero-extended to form the PA. All 34b are directly accessible
when in Sv32 mode.

In Sv39, each VA must have bits 63-39 equal to bit 38, as described.
Sv39 translation will produce a 56b PA. If the implementation has more
than 56 physical address bits, that 56b PA will be zero-extended to
the right number of bits.

Does that make sense? Hope that helps,
Dan

On 2/22/2021 3:28 AM, Gracy Ge wrote:
I reused a topic title under https://github.com/riscv/riscv-isa-manual/issues/131
And also I attached some comments in section 4.4.1 of privileged spec those confused me so much,

*A*. Sv39 implementations support a 39-bit virtual address space, divided into 4 KiB pages. An Sv39
address is partitioned as shown in Figure 4.18. Instruction fetch addresses and load and store
effective addresses, which are *64 bits* , must have bits *63–39 all equal to bit 38* , or else a page-fault
exception will occur.

*B*. When mapping between narrower and wider addresses, RISC-V usually *zero-extends* a narrower
address to a wider size. The mapping between 64-bit virtual addresses and the 39-bit usable
address space of Sv39 is not based on zero-extension but instead follows an entrenched convention
that allows an OS to use one or a few of the most-significant bits of a full-size (64-bit) virtual
address to quickly distinguish user and supervisor address regions.

I have similar issues on SV32 and SV39.
1. In SV32, access to only the low 4Gb (i.e. the top 12Gb are not accessible) in bare mode or machine mode.
Can I understand this is explicitly stated from *#B* ( *zero extends* ) in section4 4.4.1?
2. How to understand the usable address space in SV39? Shall OS make sure the address zero extend the higher bits or keep it [38] extended? IMO, statement in # *A* and # *B* is conflicted. Forgave me if I misunderstood it.
3. In sv39, what is the valid address space in bare mode or Machine mode? Is it maximum 64 bit wide? I know it is not a real case, just to make sure the ideal limitation here.
4. Last question in SV32, OS can utilize the MAPPING scheme of SV32 and get physical address used up to 16G. However currently gcc compiler for 32 bit system only have 4G memory usage, How can I compile a testcase and link them to LMA at upper 12G memory space?

Best Regards,
Gracy