[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen/x86: Adjust stack pointer in xen_sysexit
On Mon, Nov 16, 2015 at 12:11:11PM -0800, Andy Lutomirski wrote: > On Mon, Nov 16, 2015 at 11:59 AM, Borislav Petkov <bp@xxxxxxxxx> wrote: > > On Mon, Nov 16, 2015 at 11:03:22AM -0800, Andy Lutomirski wrote: > > > >> ... > >> The reader surely doesn't remember that this isn't guaranteed to be a > >> swapgs instruction on native. Using: > >> > >> ALTERNATIVE "swapgs" "" X86_FEATURE_XENPV > >> > >> would be safer (it would get rid of the SWAPGS_UNSAFE_STACK mess) and > >> much clearer. We could hide *that* behind a macro and no one would be > >> confused. (Well, they'd be confused by the fact that Xen PV handles > >> gsbase very differently from native, but that has nothing to do with > >> the macro.) > >> > >> I think we could convert piecemeal, and I wonder if this new patch for > >> 32-bit native on 4.4 (this is needed for 4.4, right?) would be a good > >> starting point. Borislav, what do you think? Would you be okay with > >> adding a Xen PV pseudofeature? > > > > AFAICT, I'd prefer this becomes rather a jump label which gets enabled > > on xen. Especially if a single pseudofeature might not be enough, > > apprently... > > Except it's not a jump. (Also, the alternatives infrastructure is IMO > much nicer than the jump label infrastructure.) > > Taking SWAPGS as an example, the semantics we need are: > > - On native, do swapgs. This *can't* be a call due to RSP issues. > - On Xen PV, swapgs will work, but it's emulated. We'd rather just nop it > out. Huh, so what's wrong with a jump: jmp 1f swapgs 1: > In principle, we could static jump over it on Xen, but that also > involves forcing the jump label to be built on old GCC versions, which > PeterZ objected to the last time I asked. :-\ > If it would make you feel better, it could be X86_BUG_XENPV :-p That doesn't matter - I just don't want to open the flood gates on pseudo feature bits. hpa, what do you think? > Are there really multiple feature bits for this stuff? I'd like to > imagine that the entry code is all either Xen PV or native/PVH/PVHVM > -- i.e. I assumed that PVH works like native for all entries. I just reacted to Boris' statement: "We don't currently have a Xen-specific CPU feature. We could, in principle, add it but we can't replace all of current paravirt patching with a single feature since PVH guests use a subset of existing pv ops (and in the future it may become even more fine-grained)." -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |