[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 series. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |