Re: [PATCH v3] x86/emul: Adjust handling of CR8_LEGACY

[Jan Beulich <jbeulich@xxxxxxxx>]

On 08.07.2026 11:59, Teddy Astie wrote:
> Le 08/07/2026 à 11:37, Jan Beulich a écrit :
>> On 08.07.2026 11:29, Teddy Astie wrote:
>>> Le 07/07/2026 à 21:49, Andrew Cooper a écrit :
>>>> --- a/xen/arch/x86/x86_emulate/decode.c
>>>> +++ b/xen/arch/x86/x86_emulate/decode.c
>>>> @@ -780,12 +780,12 @@ decode_twobyte(struct x86_emulate_state *s,
>>>>            break;
>>>>    
>>>>        case 0x20: case 0x22: /* mov to/from cr */
>>>> -        if ( s->lock_prefix && vcpu_has_cr8_legacy() )
>>>> +        if ( s->lock_prefix && vcpu_has_cr8_legacy() && s->modrm_reg == 0 
>>>> )
>>>>            {
>>>> -            s->modrm_reg += 8;
>>>> +            s->modrm_reg = 8;
>>>>                s->lock_prefix = false;
>>>>            }
>>>> -        /* fall through */
>>>> +        fallthrough;
>>>>        case 0x21: case 0x23: /* mov to/from dr */
>>>>            ASSERT(s->ea.type == OP_REG); /* Early operand adjustment 
>>>> ensures this. */
>>>>            generate_exception_if(s->lock_prefix, X86_EXC_UD);
>>>
>>> I'm fine with it; though we probably want to make sure we always
>>> advertise the AltMovCr8 feature bit as APM suggest users to always check
>>> for this before relying on this behavior.
>>
>> Why would we set the flag when hardware doesn't have it? Note the
>> vcpu_has_cr8_legacy() check there - we only engage this behavior if
>> the guest sees the feature as available.
> 
> Hmm, ok, though this bit is named as "AltMovCr8" in July 2025 APM; but 
> we name it "cr8_legacy". Has the name of the feature bit changed in APM 
> over time ?

I don't know. What I do know is that imo AltMovCr8 isn't the greatest of
all possible names. (Neither is cr8_legacy, first and foremost as it
alludes to this being a compat-mode-only thing when it isn't.)

Jan