• Jeremy Fitzhardinge's avatar
    xen: use iret directly when possible · 9ec2b804
    Jeremy Fitzhardinge authored
    Most of the time we can simply use the iret instruction to exit the
    kernel, rather than having to use the iret hypercall - the only
    exception is if we're returning into vm86 mode, or from delivering an
    NMI (which we don't support yet).
    
    When running native, iret has the behaviour of testing for a pending
    interrupt atomically with re-enabling interrupts.  Unfortunately
    there's no way to do this with Xen, so there's a window in which we
    could get a recursive exception after enabling events but before
    actually returning to userspace.
    
    This causes a problem: if the nested interrupt causes one of the
    task's TIF_WORK_MASK flags to be set, they will not be checked again
    before returning to userspace.  This means that pending work may be
    left pending indefinitely, until the process enters and leaves the
    kernel again.  The net effect is that a pending signal or reschedule
    event could be delayed for an unbounded amount of time.
    
    To deal with this, the xen event upcall handler checks to see if the
    EIP is within the critical section of the iret code, after events
    are (potentially) enabled up to the iret itself.  If its within this
    range, it calls the iret critical section fixup, which adjusts the
    stack to deal with any unrestored registers, and then shifts the
    stack frame up to replace the previous invocation.
    Signed-off-by: default avatarJeremy Fitzhardinge <jeremy@xensource.com>
    9ec2b804
asm-offsets.c 3.87 KB