>>
>>> +
>>> + if (nested) {
>>> + if (rdseed_enabled)
>>> + vmx->nested.nested_vmx_secondary_ctls_high |=
>>> + SECONDARY_EXEC_RDSEED;
>
> Arguably, this isn't necessary. A sane platform could have support for
> the RDSEED instruction without support for "RDSEED exiting." The same
> applies to INVPCID, in the code above.
I agree. It should be handled like this:
Host has RDSEED but L1 does not (via CPUID):
a) If RDSEED_EXITING is available, enable it (to fake absence)
b) If RDSEED_EXITING is available, enable it in vmcs02 (to fake absence)
b) Forbid RDSEED_EXITING for L1->L2 (in vmcs12) and via MSR
Host and L1 have RDSEED:
a) Don't set RDSEED_EXITING
b) Allow RDSEED_EXITING for L1->L2 (in vmcs12) and via MSR (if
available)
Neither has RDSEED:
a) Don't set RDSEED_EXITING
b) Forbid RDSEED_EXITING for L1->L2 (in vmcs12) and via MSR
I wonder if we would have to take care about !RDSEED but RDSEED_EXITING
(could be created in nested setups, right?)
>
>>> + else
>>> + vmx->nested.nested_vmx_secondary_ctls_high &=
>>> + ~SECONDARY_EXEC_RDSEED;
>>> + }
>>> + }
>>
>> I think it would be nicer to generalize that pattern:
>
> In general, "<opcode> exiting" or enable <opcode>" VMX capabilities
> should be forced off if the CPUID feature bit for the opcode is
> cleared (except, perhaps, for the MONITOR/MWAIT oddity).
Yes, I agree.
>
>> (We can call it after updating the MSRs too.)
>
> After updating the MSRs, perhaps the CPUID feature bit for the opcode
> should be forced on if the corresponding "allowed-1" VMX capability
> bit is set. Or, perhaps it should be an error to set the VMX
> capability bit via KVM_SET_MSRS after having already cleared the
> corresponding CPUID feature bit via KVM_SET_CPUID2.
I prefer the latter (implicit enabling sounds strange), if that doesn't
result in any other conflicts.
--
Thanks,
David
