You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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?
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 thanBit 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
The text was updated successfully, but these errors were encountered: