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

Support reverse lookup of bit offset #98

Open
zhaofengli opened this issue Sep 25, 2021 · 1 comment
Open

Support reverse lookup of bit offset #98

zhaofengli opened this issue Sep 25, 2021 · 1 comment

Comments

@zhaofengli
Copy link
Contributor

It would be nice to have a per-register function that returns the corresponding field name given a bit offset. This will be useful for generating debugging/error messages.

For example, for each VMCS control field there is a [1] corresponding MSR that contains the constraint (i.e, features supported by the processor) on the value that can be set in said control. In our hypervisor we perform the checks on the values ourselves, and Bit 28 (Load CET state) of "VM-exit controls" must be 0 would look much nicer than Bit 28 of "VM-exit controls" must be 0.

This requires a bit more changes to the code generation infrastructure, so I'm opening an issue first for some feedback on how this should be done.

[1] Sometimes two

@JaredWright
Copy link
Member

If we go down the path of generating a function that returns a field's name given the field's bit position, I foresee the following complexities:

  • Some fields are 1 bit, some fields are a range of bits
  • Registers have a name (sort of a like a weak "id") and a long name (a more human-readable version, if defined)
  • Some registers have more than one fieldset. In other words, you must decide how to interpret the register's contents based on external factors (e.g. this CPUID leaf)

This sounds possible, but I'm wondering if there is another more general approach to tackle the immediate problem you face: printing a human-friendly message when a semantic constraint is violated about a CPU's usage. What do you think about the idea outlined in Discussion #82?

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