On 03/10/2018 18:36, Jim Mattson wrote: > It seems that the best way to mock up an older CPU that doesn't > support FlexPriority is to: > (a) intercept RDMSR of IA32_VMX_PROCBASED_CTLS2 and clear bit 0 of %rdx, and > (b) intercept VMWRITE to the secondary processor-based VM-execution > controls field and emulate VMfail when a 1 is written to bit 0. Not VMWRITE, but VMLAUNCH/VMRESUME I suppose? The patch that I sent this morning adds exactly these two things to the flexpriority parameter (actually only the MSR has to be changed, because execution controls are checked against the MSR values and changing them fixes (b) as well). But it's not clear, are you suggesting to use nested virtualization (using "intercept" makes me think of nested)? That also introduces the possible bugs (and hidden bugs) from nesting, so it is worse than the module parameter. > Pushing the code higher up in the stack complicates things quite a > bit, and encourages bizarre behaviors like we have today, where, for > instance, FlexPriority support is still enumerated in the > IA32_VMX_PROCBASED_CTLS2 value synthesized for L1, and in fact, L1 can > still enable FlexPriority for L2. That certainly isn't consistent with > the behavior of old machines. Yup, I agree. In general we do have cases where we provide functionality that is not there on older machines, but for flexpriority the behavior is messy and nowhere near real hardware's. In other cases (enable_vnmi for example) it's possibly odd and we may want to change that, but the severity is smaller. Paolo
