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.coop...@citrix.com> > --- > CC: Jan Beulich <jbeul...@suse.com> > CC: Roger Pau Monné <roger....@citrix.com> > > 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
