[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 13/02/17 15:19, Jan Beulich wrote:
>>>> 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"?

SYSCALL on Intel will #UD if CS.L == 0, so you can't even use it from a
compatability mode segment.

>> 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).

Ok.  All good points.  I will drop this part of the patch and keep it
set up unconditionally.  This doesn't actually affect the rest of the


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.