When Physical Address Size < XLEN, should address check be performed on unused upper address bits?
|
Ricardo Ramirez
In RISC-V, instruction fetch addresses and load and store effective addresses are XLEN bits wide; however, an implementation can have a smaller physical address size.
When a core is in M-mode or Bare translation mode and the PA size < XLEN, what is the expectation on how the upper unused address bits are handled in regards to address checking? Is there an expectation from software? For example, should h/w fault if the upper bits are not all 0 or an extension of the PA msb, or can the core simply ignore those bits? Regards, Ricardo |
|
|
|
Greg Favor
On Thu, Sep 9, 2021 at 12:00 PM <ricardo.ramirez@...> wrote: When a core is in M-mode or Bare translation mode and the PA size < XLEN, what is the expectation on how the upper unused address bits are handled in regards to address checking? Is there an expectation from software? Architecturally addresses are always XLEN in size. PA's are unsigned values and are zero-extended from their implemented size up to XLEN size. Those extra bits may not physically exist, but they do exist logically for the sake of performing PMA and PMP checks. Greg.
|
|
|
|
Ricardo Ramirez
Thanks for the response, Greg.
To make sure I understand, are you saying that when in M-mode/Bare-mode, addresses generated by s/w should be zero-extended from their implemented PA size up to XLEN size?
Ricardo
From: Greg Favor <gfavor@...>
Sent: Thursday, September 9, 2021 12:40 PM To: Ricardo Ramirez <ricardo.ramirez@...> Cc: tech-privileged <tech-privileged@...> Subject: Re: [RISC-V] [tech-privileged] When Physical Address Size < XLEN, should address check be performed on unused upper address bits?
On Thu, Sep 9, 2021 at 12:00 PM <ricardo.ramirez@...> wrote:
Architecturally addresses are always XLEN in size. PA's are unsigned values and are zero-extended from their implemented size up to XLEN size. Those extra bits may not physically exist, but they do exist logically for the sake of performing PMA and PMP checks.
Greg.
|
|
|
|
Greg Favor
Actually, I realize that I was imprecise and probably flat out misleading. Address calculations (e.g. by load/store instructions) are performed to full XLEN size, producing a full XLEN-wide value (irrespective of privilege mode and translation mode). In the case of a translated mode, the address is treated as a VA whose high bits are checked for having proper sign extension with respect to the specific translation mode (e.g. Sv39), and then translated. The PA that results from translation is a full XLEN-wide value (zero-extended from the leaf PTE's PPN field) that logically is then subjected to PMA/PMP checks. In an untranslated mode (i.e. M-mode or Bare mode) one effectively starts with the full XLEN-wide calculated PA - that again is subject to PMA/PMP checks. Where one can physically take advantage of "implementing <XLEN PA bits" is in the various post-PTE / post-ALU address data paths, cache tags, etc. - which can all take advantage of the fact that the PMA check should raise an Access Fault if the size of the PA is larger than the "implemented PA size". So, for example, one could immediately check the high bits of the PTE's/ALU's output for all "unimplemented" PA bits being zero (and raise an Access fault if any are not zero). All downstream logic can then work with <XLEN-wide physically implemented address values knowing that the physically non-existent bits must be zero. Greg On Thu, Sep 9, 2021 at 12:49 PM Ricardo Ramirez <ricardo.ramirez@...> wrote:
|
|
|
|
Ricardo Ramirez
Greg,
Thanks. That’s great explanation.
RR
From: Greg Favor <gfavor@...>
Sent: Thursday, September 9, 2021 1:55 PM To: Ricardo Ramirez <ricardo.ramirez@...> Cc: tech-privileged <tech-privileged@...> Subject: Re: [RISC-V] [tech-privileged] When Physical Address Size < XLEN, should address check be performed on unused upper address bits?
Actually, I realize that I was imprecise and probably flat out misleading. Address calculations (e.g. by load/store instructions) are performed to full XLEN size, producing a full XLEN-wide value (irrespective of privilege mode and translation mode). In the case of a translated mode, the address is treated as a VA whose high bits are checked for having proper sign extension with respect to the specific translation mode (e.g. Sv39), and then translated. The PA that results from translation is a full XLEN-wide value (zero-extended from the leaf PTE's PPN field) that logically is then subjected to PMA/PMP checks. In an untranslated mode (i.e. M-mode or Bare mode) one effectively starts with the full XLEN-wide calculated PA - that again is subject to PMA/PMP checks.
Greg
On Thu, Sep 9, 2021 at 12:49 PM Ricardo Ramirez <ricardo.ramirez@...> wrote:
|
|
|