-----Original Message-----
From: Vedvyas Shanbhogue [mailto:ved@...]
Sent: Thursday, August 19, 2021 4:10 PM
To: Xinhaoqu (Freddie) <xinhaoqu@...>; tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Effective address width when S mode and U mode has different XLEN

On 8/19/21 9:50 AM, Xinhaoqu (Freddie) wrote:

Oops, have we found a contradiction in the spec?

If we sign-extend the 32-bit PC 0x80000000 as described in the Machine-level ISA, then the 64-bit VA will not be in the "lowest 4GiB of the address space", as the Supervisor-level ISA requires.

I believe the two text are complementary. The first is saying what value is stored in the destination register - e.g. pc and rd by JALR - this is the sign extended value. The second text is what is the width of the effective address for load/store/instruction-fetch - this is the module 2^UXLEN. Does that look right?

-ved

-----Original Message-----
From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Vedvyas Shanbhogue
Sent: Thursday, August 19, 2021 3:41 PM
To: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Effective address width when S mode and U mode has different XLEN

In fact, the spec have already chosen option 1, or sign-extension.
This description below appears clear to me.

https://github.com/riscv/riscv-isa-manual/blob/fcbcb958aa49515e6345b1c
08b3165f1db7bab67/src/machine.tex#L656
<https://github.com/riscv/riscv-isa-manual/blob/fcbcb958aa49515e6345b1
c08b3165f1db7bab67/src/machine.tex#L656>

Whenever XLEN in any mode is set to a value less than the widest
supported XLEN, all operations

must ignore source operand register bits above the configured XLEN,
and must sign-extend results

to fill the entire widest supported XLEN in the destination register.
Similarly, pc bits above XLEN

are ignored, and when the pc is written, it is sign-extended to fill
the widest supported XLEN.

Specifically for UXLEN which was the op, section 4.1.1.1 provides this guidance on effective address:

"If UXLEN < SXLEN, user-mode instruction-fetch addresses and load and store effective addresses
are taken modulo 2^UXLEN. For example, when UXLEN=32 and SXLEN=64, user-mode memory
accesses reference the lowest 4 GiB of the address space."

This also to me seems the most natural way to do this.

- ved

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Chang Liu
Sent: Thursday, August 19, 2021 2:43 PM
To: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Effective address width when S mode and U mode has different XLEN

 

This will affect the hardware design: when the processor generates a instruction or data fetch request in U mode (XLEN 32) , how to extend the MSBs of the virtual address. For example, when U mode fetches the next instruction of the PC address of 0x7FFF_FFFE, what virtual address (39 bits) should be used by the hardware for page table walk (because S mode uses SV-39). Option 1 is sign extension (0xFF_8000_0000), and option 2 is zero extension (0x00_8000_0000). If the extension method of the hardware is different from what the OS expects, a page fault will occur.

 

Option 1 has a smaller change on the hardware, because it is similar to the extension method of writing back 32 bits data to 64-bit registers:

The compiler and calling convention maintain an invariant that all 32-bit values are held in a sign-extended format in 64-bit registers. Even 32-bit unsigned integers extend bit 31 into bits 63 through 32.

But for the OS, option 2 is more friendly. Because the U mode program gets a continuous 4GB virtual address space.

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Chang Liu
Sent: Thursday, August 19, 2021 5:54 AM
To: tech-privileged@...
Subject: [RISC-V] [tech-privileged] Effective address width when S mode and U mode has different XLEN

 

In a system using SV-39, RISC-V privileged spec defines the behavior of address calculation and page fault detection:
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.

My question is in a system where S mode and U mode use different XLENs, what is the bit width of the effective address?

For example, the XLEN of M mode and S mode is 64, and SV-39 vertual memory system is used. The XLEN of U mode is 32 (specified by UXL). There are two possible definitions for the bit width of the effective address in U mode:

1.     The bit width of the effective address in U mode is still 64. The 32-bit address calculation result will be sign-extended to 64-bit, and then the page fault will be detected according to the definition above. This will cause the virtual address space of U mode to be divided into two separate 2GB address spaces:
0x00_0000_0000-0x00_7FFF_FFFF and 0xFF_8000_0000-0xFF_FFFF_FFFF

2.     The bit width of the effective address in U mode is 32. This means that the effective address calculated by all instructions and load/store is only valid in the LSB 32, and the MSBs should be zero-extended to 64 bits. The virtual address space of U mode is still a continuous 4GB:
0x00_0000_0000-0x00_FFFF_FFFF

Please clarify the bit width of the effective address in systems that support different XLENs in different privileged modes. This will affect the processor's processing of the MSBs of the virtual address and the allocation principle of the operating system's virtual address space.