Re: [PATCH v9 15/22] KVM: x86: Mark CR4.FRED as not reserved

[Chao Gao <chao.gao@intel.com>]

On Wed, Mar 04, 2026 at 04:58:14PM -0800, Sean Christopherson wrote:
>On Wed, Nov 19, 2025, Chao Gao wrote:
>> On Sun, Oct 26, 2025 at 01:19:03PM -0700, Xin Li (Intel) wrote:
>> >From: Xin Li <xin3.li@intel.com>
>> >
>> >The CR4.FRED bit, i.e., CR4[32], is no longer a reserved bit when
>> >guest cpu cap has FRED, i.e.,
>> >  1) All of FRED KVM support is in place.
>> >  2) Guest enumerates FRED.
>> >
>> >Otherwise it is still a reserved bit.
>> >
>> >Signed-off-by: Xin Li <xin3.li@intel.com>
>> >Signed-off-by: Xin Li (Intel) <xin@zytor.com>
>> >Tested-by: Shan Kang <shan.kang@intel.com>
>> >Tested-by: Xuelian Guo <xuelian.guo@intel.com>
>> 
>> I am not sure about two things regarding CR4.FRED and emulator code:
>> 
>> 1. Should kvm_set_cr4() reject setting CR4.FRED when the vCPU isn't in long
>>    mode? The concern is that emulator code may call kvm_set_cr4(). This could
>>    cause VM-entry failure if CR4.FRED is set in other modes.
>
>This has nothing to do with the emulator, KVM will intercept and emulate all
>CR4 writes that toggle CR4.FRED.

I think I misanalyzed this.

For normal (non-emulator) code paths, kvm_register_read() drops the high-32 bits
which ensures CR4.FRED won't be set outside 64-bit mode.

Looking at the emulator code again, the Op3264 flag and
fetch_register_operand() will also prevent CR4.FRED from being set outside
64-bit mode.

The only scenario where CR4.FRED could be set in non-64-bit mode is through
userspace VMM's CR4 writes. But, KVM currently allows userspace to write
invalid values anyway, so this isn't a problem.

>KVM also needs to enforce leaving 64-bit mode
>with CR4.FRED=1.

Yes.