Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question about did check in IODIR.INVAL_PDT #319

Closed
viktoryou opened this issue May 20, 2024 · 8 comments
Closed

Question about did check in IODIR.INVAL_PDT #319

viktoryou opened this issue May 20, 2024 · 8 comments

Comments

@viktoryou
Copy link

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
Copy link
Collaborator

ved-rivos commented May 20, 2024

The check was missing. Its included in PR #323

@viktoryou
Copy link
Author

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
Copy link
Collaborator

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

@viktoryou
Copy link
Author

I see. Thanks for your help.

@viktoryou
Copy link
Author

viktoryou commented May 21, 2024

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
Copy link
Collaborator

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:

  • 1LVL - 6 bits
  • 2LVL- 15 bits
  • 3LVL - 24 bits
    In base format the following device ID widths are supported:
  • 1LVL - 7 bits
  • 2LVL - 16 bits
  • 3LVL - 24 bits

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
Copy link
Author

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
Copy link
Collaborator

Right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants