Re: [Xen-devel] [PATCH 2/4] x86/setup: Minor cleanup to host SYSCALL MSR handling

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.02.17 at 15:32, <andrew.cooper3@xxxxxxxxxx> wrote:
> Xen's choice of the MSR_STAR value is constant across all pcpus.  Introduce a
> new define and use it to avoid the opencoding in subarch_percpu_traps_init()
> and restore_rest_processor_state().
> 
> Despite Intel hardware having an MSR_CSTAR register, nothing actually uses it
> as the SYSCALL instruction raises #UD out of 64bit mode, meaning that

Did you mean "32-bit"?

> MSR_LSTAR is the only %rip value hardware will use.
> 
> Therefore, only create a CSTAR trampoline stub, and save/restore the CSTAR
> value across suspend/resume on AMD hardware.  MSR_CSTAR should now be
> consistently 0 on Intel hardware.

It's not documented to be zero when coming out of reset, and
you never write zero to it.

Plus, if there would be an Intel CPU supporting compat mode
SYSCALL, we'd end up with PV guests having a way to transfer
control to ring 0 execution at RIP 0. Sadly the instruction doesn't
#GP(0) on a null selector found in STAR, so I think we need to
keep storing a valid pointer into CSTAR as long as we set
EFER.SCE (which we can't really avoid).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel