lkml.org 
[lkml]   [2015]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [Xen-devel] [PATCH] xen/x86: Adjust stack pointer in xen_sysexit
    On Tue, Nov 17, 2015 at 11:29 AM, Andrew Cooper
    <andrew.cooper3@citrix.com> wrote:
    > On 17/11/15 19:16, Andy Lutomirski wrote:
    >> On Tue, Nov 17, 2015 at 11:12 AM, Andrew Cooper
    >> <andrew.cooper3@citrix.com> wrote:
    >>> On 17/11/15 18:49, Andy Lutomirski wrote:
    >>>> On Nov 17, 2015 6:40 AM, "Boris Ostrovsky" <boris.ostrovsky@oracle.com> wrote:
    >>>>> On 11/16/2015 04:55 PM, H. Peter Anvin wrote:
    >>>>>> On 11/16/15 12:22, Borislav Petkov wrote:
    >>>>>>> Huh, so what's wrong with a jump:
    >>>>>>>
    >>>>>>> jmp 1f
    >>>>>>> swapgs
    >>>>>>> 1:
    >>>>>>>
    >>>>>> What is the point of that jump?
    >>>>>>
    >>>>>>>> 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?
    >>>>>> Pseudo feature bits are fine, we already have plenty of them. They make
    >>>>>> sense as they let us reuse a lot of infrastructure.
    >>>>>
    >>>>> So how about something like this? And then I think we can remove usergs_sysret32 and irq_enable_sysexit pv ops completely as noone will use them (lguest doesn't set them)
    >>>>>
    >>>> Looks good to me. Does Xen have any sysexit/sysret32 equivalent to
    >>>> return to 32-bit user mode? If so, it could be worth trying to wire
    >>>> it up by patching the jz instead of the test instruction.
    >>> From the guests point of view, there is only hypercall_iret.
    >> Doesn't hypercall_iret have flags that ask for different behavior,
    >> though? (VG_syscall or whatever for the 64-bit case?)
    >
    > The one and only flag is VGCF_in_syscall
    >
    > Xen has its own logic for choosing between sysretq/sysretl if
    > VGCF_in_syscall, but will end up on an iret path in all other
    > circumstances.

    In that case, a nicer version of this patch could preserve the new
    sysret-or-iret decision (on 64-bit kernels in the compat path) and use
    it to set VGCF_in_syscall. This might work considerably better now
    than it ever would have, since Linux now tries to use sysret32 on
    *all* 64-bit CPUs, and the way it's structured for compat is just a
    flag (the testl %eax,%eax thing) that indicates that sysret32 is okay.

    Anyway, that can be a followup patch.

    --Andy


    \
     
     \ /
      Last update: 2015-11-17 21:01    [W:2.268 / U:0.344 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site