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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.03.2025 16:25, Andrew Cooper wrote:
> The CR8_LEGACY feature was introduced in the K8 Revision F.  It doesn't exist
> in prior revisions of the K8.
> 
> Furthermore, from APM Vol2 3.1.5 CR8 (Task Priority Register, TPR):
> 
>   The AMD64 architecture introduces a new control register, CR8, defined as
>   the task priority register (TPR).
> 
> Give CR8_LEGACY a dependency on LM, seeing as CR8 doesn't exist on pre-64bit
> CPUs.

But that's not what LM stands for in the dependencies. If you want to run a
guest strictly as 32-bit one, you could suppress exposure of LM. That
shouldn't also suppress the ability to access CR8 then, though - the LOCK
way of accessing was - aiui - specifically added to allow access to it from
a 32-bit kernel.

> Additionally, from APM Vol3 4 System Instructions MOV CRn:
> 
>   CR8 can be read and written in 64-bit mode, using a REX prefix.  CR8 can be
>   read and written in all modes using a LOCK prefix instead of a REX prefix to
>   specify the additional opcode bit.
> 
> i.e. the LOCK prefix serves as an alternative encoding for REX.R.
> 
> Switch decode_twobyte() from += 8 to |= 8 to better match the description
> given.  Other indications that the encoding isn't additive are that the CR
> intercepts stop at 15, that LOCK MOV CR8 generates #UD rather than becoming a
> CR0 access.
> 
> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> ---
> CC: Jan Beulich <JBeulich@xxxxxxxx>
> CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
> 
> Also, designers never put an ADD into silicon if they can possibly avoid it,
> because it's slow and large compared to the single OR gate needed in this
> case.

My reading of the respective doc was never resulting in something unambiguous.
I find this argument far more convincing than anything that's in the doc.

I probably should have tried out REX + LOCK. Maybe I even did and concluded
from it faulting that the two things are cumulative.

Jan