Open
Description
BRS UEFI_030 requires 1:1 mapping. This can only work if the RAM regions fit within the bottom part of the virtual address space. If you were unlucky enough to place RAM somewhere ridiculously high (say starting at bit 47 on an Sv48 system), then you could never meet this rule. It's also possible that NUMA designs end up with a large enough hole between the two DDR ranges, which too could cause for some of the memory to be inaccessible in the UEFI environment (which is not too fatal, provided the testing is done before the MMU is enabled).
Here's what the priv spec says:
- Sv39: 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.
- Sv48: Instruction fetch addresses and load and store effective addresses, which are 64 bits, must have bits 63–48 all equal to bit 47, or else a page-fault exception will occur.
- Sv57: Instruction fetch addresses and load and store effective addresses, which are 64 bits, must have bits 63–57 all equal to bit 56, or else a page-fault exception will occur.
Do we need to add a rule here or just assume the folks reading the BRS will totally think about 1:1 mapping constraints (and communicate these to SoC architects)?
Metadata
Assignees
Labels
No labels
Activity