search

riscv-non-isa / riscv-iommu

RISC-V IOMMU Specification
https://jira.riscv.org/browse/RVG-55
Creative Commons Attribution 4.0 International
72 stars 14 forks source link

Question about ddtp.ppn update in RV32 #329

Closed viktoryou closed 1 month ago

viktoryou commented 1 month ago

In RV32, only the low order 32-bits of the register (22-bit PPN and 4-bit iommu_mode) need to be written.

From my understanding, it is not prohibited that RV32 and RV64 scheme are both supported in one IOMMU hardware. Is that right? From the model, when capabilities.pas is larger than 34, and both RV32 and RV64 supported, then higher order of ppn in ddtp may be updated in RV32 when the writing value is not properly set. For example, bits of ppn[capabilities.pas-3:32] are non-zeroes. Is it an unspecified behavior, or the hardware would take the responsibility to avoid that update?

ved-rivos commented 1 month ago

It is legal to support both RV32 and RV64 page based virtual memory systems. The PPN in ddtp may be as wide as the PA size supported by hardware. If the programmed address is not accessible due to restrictions such as those posed by PMA and/or PMP then it would subsequently lead to a DDT entry load access fault. If no such fault occurs then the IOMMU operates normally in such configuration.

viktoryou commented 1 month ago

The PPN in ddtp may be as wide as the PA size supported by hardware.

If the PPN in ddtp programs wider than PA size supported by hardware, the model would ignore the writability of the bits out of range. Now it seems like a suggest, but not a restriction.

What about the purpose of this originally quoted sentence in the spec?

In RV32, only the low order 32-bits of the register (22-bit PPN and 4-bit iommu_mode) need to be written.

It seems just like a reminder that, in a RV32-only system, only 32-bit ddtp is visible. Then could I come to a conclusion that, in an RV64 or an RV32 and RV64 mixed system, there should be no constraints in the writablity of ddtp by hardware. Am I right?

ved-rivos commented 1 month ago

If the PPN in ddtp programs wider than PA size supported by hardware, the model would ignore the writability of the bits out of range. Now it seems like a suggest, but not a restriction.

As noted - "as wide as PA size" - not "wider than the PA size"

It seems just like a reminder that, in a RV32-only system, only 32-bit ddtp is visible. Then could I come to a conclusion that, in an RV64 or an RV32 and RV64 mixed system, there should be no constraints in the writablity of ddtp by hardware. Am I right?

That is an informative note that in RV32 systems since SW can only access upto 2^34 bit memory it is not unlikely SW will program memory that it cannot access into the PPN.

viktoryou commented 1 month ago

Thanks for clarification. But I could not find a similar description as "The PPN in ddtp may be as wide as the PA size supported by hardware" from spec. My concern is whether the writablity of ddtp.ppn is constrained by PA width is not that clear.

When the PPN in ddtp should not be wider than the PA size, then the value of ppn update would be masked, else the translation may leads to DDT entry load access fault based on a misconfigured ddtp.ppn. I think an implementation may need to know which one to follow.

ved-rivos commented 1 month ago

My concern is whether the writablity of ddtp.ppn is constrained by PA width is not that clear.

It is not. The PPN field is a WARL field. An implementation would typically have it as wide as the widest PA it can support but an implementation is allowed to make it wider - for instance an implementation may implement all bits in the register. For WARL fields, the legal values can be determined by software attempting to write a desired setting then reading to see if the value was retained. For instance SW may write all 1s and read back how many 1 bits were retained.

The PA size supported by the IOMMU does not imply that all of that is accessible. For instance, consider an implementation that supports 34-bit wide PA. This implementation is able to address 64 GB of memory. However in a particular platform all 64 GB may not be accessible. For example, if in a platform there is only 2 GB of DRAM plugged in then the rest of that addressable memory space is unimplemented and an access to the unimplemented memory may lead to an access fault.

It is responsibility of SW to a) determine the legal width of the PPN field using WARL discover b) determine valid memory ranges in the platform c) program an address into the PPN which is legal and valid.

viktoryou commented 1 month ago

That's clear. Thanks a lot.