On Fri, 28 Jul 2023 at 02:17, Richard Henderson
<richard.hender...@linaro.org> wrote:
>
> On 7/27/23 14:36, Ard Biesheuvel wrote:
> > On Thu, 27 Jul 2023 at 19:56, Richard Henderson
> > <richard.hender...@linaro.org> wrote:
> >>
> >> On 7/26/23 08:01, Richard Henderson wrote:
> >>> On 7/26/23 01:17, Ard Biesheuvel wrote:
> >>>> Hints welcome on where the architectural behavior is specified, and in 
> >>>> particular,
> >>>> whether or not other 64-bit GPRs can be relied upon to preserve their 
> >>>> full 64-bit
> >>>> length values.
> >>>
> >>> No idea about chapter and verse, but it has the feel of being part and 
> >>> parcel with the
> >>> truncation of eip.  While esp is always special, I suspect that none of 
> >>> the GPRs can be
> >>> relied on carrying all bits.
> >>
> >> Coincidentally, I was having a gander at the newly announced APX extension 
> >> [1],
> >> and happened across
> >>
> >> 3.1.4.1.2 Extended GPR Access (Direct and Indirect)
> >>
> >>       ... Entering/leaving 64-bit mode via traditional (explicit)
> >>       control flow does not directly alter the content of the EGPRs
> >>       (EGPRs behave similar to R8-R15 in this regard).
> >>
> >> which suggests to me that the 8 low registers are squashed to 32-bit
> >> on transition to 32-bit IA-32e mode.
> >>
> >> I still have not found similar language in the main architecture manual.
> >>
> >
> > Interesting - that matches my observations on those Ice Lake cores:
> > RSP will be truncated, but preserving/restoring it to/from R8 across
> > the exit from long mode works fine.
>
> Found it:
>
> Volume 1 Basic Architecture
> 3.4.1.1 General-Purpose Registers in 64-Bit Mode
>
> # Registers only available in 64-bit mode (R8-R15 and XMM8-XMM15)
> # are preserved across transitions from 64-bit mode into compatibility mode
> # then back into 64-bit mode. However, values of R8-R15 and XMM8-XMM15 are
> # undefined after transitions from 64-bit mode through compatibility mode
> # to legacy or real mode and then back through compatibility mode to 64-bit 
> mode.
>

Thanks. Not what I was hoping though ...

Reply via email to