search

riscv-non-isa / riscv-iommu

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

Question about did check in IODIR.INVAL_PDT #319

Closed viktoryou closed 2 months ago

viktoryou commented 2 months ago

From the spec, in Chapter 3.1.3,

The DV operand indicates if the device ID (DID) operand is valid. The DV operand must be 1 for IODIR.INVAL_PDT else the command is illegal. When DV operand is 1, the value of the DID operand must not be wider than that supported by the ddtp.iommu_mode.

However, in the model, DID check based on ddtp.iommu_mode is missing, referring to the code. Could you help to check that?

ved-rivos commented 2 months ago

The check was missing. Its included in PR #323

viktoryou commented 2 months ago

Besides the check with the maximum device ID width supported, from my understanding, model should also check did in IODIR.INVAL_PDT or IODIR.INVAL_DDT under the dynamic ddtp.iommu_mode. I think another missing check may be like code.

ved-rivos commented 2 months ago

The commands only need to look for the maximum width and not the current mode.

viktoryou commented 2 months ago

I see. Thanks for your help.

viktoryou commented 2 months ago

I get a problem in whether the width supported by the ddtp.iommu_mode is equivalent to the maximum width. From the guidelines in Chapter 6.2,

Determine the values supported by ddtp.iommu_mode by writing legal values and reading it to see if the value was retained. Stop and report a failure if the supported modes do not support the required Dw.

If the 3LVL is supported and extended-format device-contexts are used, would the Dw (device _id width) between 16-bits and 24-bits all be allowed? How could we further get the exact Dw from the software's view?

Also, should the too wide check based on Dw be applied to other possible usage of did, like IOVA translation process?

ved-rivos commented 2 months ago

If the 3LVL is supported and extended-format device-contexts are used, would the Dw (device _id width) between 16-bits and 24-bits all be allowed? How could we further get the exact Dw from the software's view?

In extended format the following device ID widths are supported:

In extended-format with 3LVL, all 24 bits are used to index into DDT - the top 9 bits into the root page of the DDT, the next 9 bits into the page linked to the entry in root page, and the last 6 bits to index into the last level to determine the leaf entry - See FIg 10.

Also, should the too wide check based on Dw be applied to other possible usage of did, like IOVA translation process?

For this purpose the current mode needs to be used - see Fig 10 and Fig 11 - as this process needs to use the bits to index into memory. For the purposes of invalidation, the cache tags of an implementation are the widest supported. For instance an implementation that supports 3LVL with extended-format will have a device_id tag of 24 bits in its caches. This hardware tag width does not change based on current DDT mode.

viktoryou commented 2 months ago

So only 6-bits, 15-bits, 24-bits width is allowed for device id in extended format, and 7-bits, 16-bits, 24-bits width in base format, right?

ved-rivos commented 2 months ago

Right.