On 07/10/19 21:54, Sean Christopherson wrote: >> For QEMU, we're defining a feature as supported if a feature can be >> turned both on and off. Since msr_low and msr_high can be defined >> respectively as must-be-one and can-be-one, the features become >> "msr_high & ~msr_low". > > That makes sense for Qemu, but I don't think it's appropriate for this > type of reporting. E.g. if EPT and Unrestricted Guest are must-be-one on > a hypothetical (virtual) CPU, it'd be odd to not list them as a supported > feature. > > For actual hardware (well, Intel hardware), as proposed it's a moot point. > The only features that are must-be-one (even without "true" MSRs) and are > documented in the SDM are CR3_LOAD_EXITING, CR3_STORE_EXITING, > SAVE_DEBUG_CONTROLS, and LOAD_DEBUG_CONTROLS, none of which are reported > in /proc/cpuinfo. > >> Also, shouldn't this use the "true" feature availability MSRs if available? > > Only if incorporating the "& ~msr_low" can-be-one logic. If a feature is > considered supported if it must-be-one or can-be-one then the true MSR and > vanilla MSR will yield the same feature set. Ok, that all makes sense. Paolo
