Skip to content

Commit

Permalink
OMISA: enable prototyping/testing for Sv57
Browse files Browse the repository at this point in the history
  • Loading branch information
@terpstra
terpstra committed May 12, 2020
1 parent b67bfac commit e9beab8
Showing 1 changed file with 3 additions and 0 deletions.
3 changes: 3 additions & 0 deletions src/main/scala/diplomaticobjectmodel/model/OMISA.scala
View file
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,8 @@ case object Bare extends OMAddressTranslationMode
case object Sv32 extends OMAddressTranslationMode
case object Sv39 extends OMAddressTranslationMode
case object Sv48 extends OMAddressTranslationMode
// unratified/subject-to-change in the RISC-V priviledged ISA specification:
case object Sv57 extends OMAddressTranslationMode

trait OMBaseInstructionSet extends OMEnum
case object RV32E extends OMBaseInstructionSet
Expand Down Expand Up @@ -86,6 +88,7 @@ object OMISA {
case 32 if (pgLevels == 2) => Sv32
case 64 if (pgLevels == 3) => Sv39
case 64 if (pgLevels == 4) => Sv48
case 64 if (pgLevels == 5) => Sv57
case _ => throw new IllegalArgumentException(s"ERROR: Invalid Xlen/PgLevels combination: $xLen/$pgLevels")
}

Expand Down

8 comments on commit e9beab8

@ingallsj
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be Sv57 or Sv55?

@terpstra
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this comment. Sv57 would be the name for 57 bits of virtual address and another page table level in the RISC-V spec. In our rocket/bullet implementations, that results in up to 2^56 bytes of physical memory. With a 50/50 MMIO/memory split, you are down to 55bits of memory bits.

@ingallsj
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sv55 would save the top byte of the Virtual Address for Memory Tagging.
Sv56 would provide the same size virtual and physical memory address ranges.
Sv57 would continue the RV64 pattern of 9 Virtual Address bits per page level.
Which of these options is the RISC-V Privileged Spec going to pick? Is this already decided?

@ingallsj
Copy link
Contributor

@ingallsj ingallsj commented on e9beab8 May 15, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On further thought, I'm tying Rocket-chip and RISC-V too closely together in my head. You commented it as unratified, good, carry on!

@terpstra
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My assumption is we would continue the RV64 9-bit pattern. Frankly, I want even more bits than Sv57. :-P So in my dreams, they would add a Sv66 and reclaim the 10 reserved bits for PPN[3] allowing 66 physical bits and 64 virtual bits. @aswaterman 🙏

@aswaterman
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You commented it as unratified, good, carry on!

That's why I think it's OK for now. But my guess is that Sv57 actually will end up getting standardized how Wes expects, and the tagging extension will be orthogonal to SvXX mode.

reclaim the 10 reserved bits for PPN[3] allowing 66 physical

Unfortunately I don't see that happening... maybe we'll be able to claw back another 3-4 bits.

@terpstra
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a page tagging extension for RISC-V in the works? 56 physical address bits (32PiB) is not a lot if you have flat addressing across multiple nodes in a data center, even just for DRAM. You only need 512GiB on 64k servers to hit it. Apparently, google had 220k nodes just for cloud services in 2017. Meanwhile, storage companies still only ship cold storage in exabytes/year. I guess RV128 will eventually be necessary, even if we had 66 physical bits. That, or you just don't use flat physical addressing (aka: how it's always been done).

@aswaterman
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tagging extension isn't really in the works yet, but it has been requested and is being superficially discussed.

I agree with your conclusion that the solution is to either use RV128 or give up on flat byte-addressability across a datacenter or cloud. Ease of failure containment and concerns about security will continue to make the "don't use flat addressing" approach appealing, probably long after the RV128-style flat-addressing approach takes off.

Please sign in to comment.