On Wed, Jun 22, 2022 at 10:00:29AM +0200, Vitaly Kuznetsov wrote: > Sean Christopherson <seanjc@xxxxxxxxxx> writes: > > > On Tue, Jun 14, 2022, Anirudh Rayabharam wrote: > >> On Mon, Jun 13, 2022 at 04:57:49PM +0000, Sean Christopherson wrote: > > ... > > >> > > >> > Any reason not to use the already sanitized vmcs_config? I can't think of any > >> > reason why the nested path should blindly use the raw MSR values from hardware. > >> > >> vmcs_config has the sanitized exec controls. But how do we construct MSR > >> values using them? > > > > I was thinking we could use the sanitized controls for the allowed-1 bits, and then > > take the required-1 bits from the CPU. And then if we wanted to avoid the redundant > > RDMSRs in a follow-up patch we could add required-1 fields to vmcs_config. > > > > Hastily constructed and compile-tested only, proceed with caution :-) > > Independently from "[PATCH 00/11] KVM: VMX: Support TscScaling and > EnclsExitingBitmap whith eVMCS" which is supposed to fix the particular > TSC scaling issue, I like the idea to make nested_vmx_setup_ctls_msrs() > use both allowed-1 and required-1 bits from vmcs_config. I'll pick up > the suggested patch and try to construct something for required-1 bits. I tried this patch today but it causes some regression which causes /dev/kvm to be unavailable in L1. I didn't get a chance to look into it closely but I am guessing it has something to do with the fact that vmcs_config reflects the config that L0 chose to use rather than what is available to use. So constructing allowed-1 MSR bits based on what bits are set in exec controls maybe isn't correct. Thanks! - Anirudh.
