On Wed, 2018-01-31 at 12:18 -0800, Jim Mattson wrote: > On Wed, Jan 31, 2018 at 12:01 PM, KarimAllah Ahmed wrote: > > > > > but save_spec_ctrl_on_exit is also set for L2 write. So once L2 writes > > to it, this condition will be true and then the bitmap will be updated. > So if L1 or any L2 writes to the MSR, then save_spec_ctrl_on_exit is > set to true, even if the MSR permission bitmap for a particular VMCS > *doesn't* allow the MSR to be written without an intercept. That's > functionally correct, but inefficient. It seems to me that > save_spec_ctrl_on_exit should indicate whether or not the *current* > MSR permission bitmap allows unintercepted writes to IA32_SPEC_CTRL. > To that end, perhaps save_spec_ctrl_on_exit rightfully belongs in the > loaded_vmcs structure, alongside the msr_bitmap pointer that it is > associated with. For vmcs02, nested_vmx_merge_msr_bitmap() should set > the vmcs02 save_spec_ctrl_on_exit based on (a) whether L0 is willing > to yield the MSR to L1, and (b) whether L1 is willing to yield the MSR > to L2. Reading and writing this MSR is expensive. And if it's yielded to the guest in the MSR bitmap, that means we have to save its value on vmexit and set it back to zero. Some of the gymnastics here are explicitly done to avoid having to do that save-and-zero step unless the guest has *actually* touched the MSR. Not just if we are *willing* to let it do so. That's the whole point in the yield-after-first-write dance.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
