Re: [PATCH v10 11/28] KVM: x86: Add a helper to detect if FRED is enabled for a vCPU

[Sohil Mehta]

On 11/4/2026 9:16 PM, Binbin Wu wrote:
>> Is the suggestion to add an explicit check in kvm_set_cr0() that
>> mirrors the PCIDE one? But there isn't a fault specified by the spec for
>> this case.
> 
> Had a second thought. As you mentioned below, if em_{jmp,call,ret}_far() is
> triggered and CS.L is cleared on ring 0, even KVM doesn't check FRED status on
> far transitions, the next VM entry would fail.  So I think it's not needed
> to mirror the PCIDE for FRED in kvm_set_cr0().
> 

Yes, agreed. I'll avoid the check in kvm_set_cr0().

>>
>> Sean also requested negative tests for things like leaving 64-bit mode
>> with FRED=1. But, I am not sure how to test this.
> 
> Maybe it can use KVM_FEP to force the instruction emulation in kvm sefltest
> when force_emulation_prefix for KVM.
> 

Okay. I'll add a FEP test that validates the emulator's far jmp/call/ret
behavior.

>>
>> AI tells me such a mode change can happen with emulated far transfer
>> through an MMIO far pointer. "em_jmp_far(), em_call_far(), em_ret_far()
>> and __load_segment_descriptor() have no FRED checks, so none of them
>> raise the #GP that FRED spec 8.2 requires."
>>
>> Chao had brought up enhancing emulator code and making it FRED aware
>> [1]. I am wondering if we should revisit it?
> 
> Without the check the next VM-entry fails the guest-state check according to
> FRED spec 11.5.2.3 ("If the DPL value in the SS attributes field is 0, the L
> bit in the CS attributes field (bit 13) must be 1") VS. With the check, raise
> #GP instead.
> 
> Not sure about the maintainers' preference. But a check on FRED in
> __load_segment_descriptor() looks simple though.
> 

I am inclined to add the check as well. So, I'll include it unless
someone says otherwise (or it gets complicated during implementation).