Re: [Xen-devel] [PATCH 6/6] mini-os/x86-64 entry: check against nested events and try to fix up

[Xu Zhang <xzhang54@xxxxxxx>]

On 03/09/2013 03:19 PM, Samuel Thibault wrote:
> > +               andb $KERNEL_CS_MASK,CS(%rsp)      # CS on stack might have 
> > changed
> I don't see why this.
Thank you for all your comments and acks. :-)

    ...
    /* Direct iret to kernel space. Correct CS and SS. */
    orb   $3,1*8(%rsp)
    orb   $3,4*8(%rsp)
1:  iretq
    ...

HYPERVISOR_IRET is part of the critical section. It could be the case 
that a nested event comes immediately after we set the lowest byte of 
on-stack CS from 0 to 3 (orb   $3,1*8(%rsp)). After invoking the fixup 
routine, we want the stack frame to be exactly the same of the original one.
One scenario this could be useful is that if mini-os had an userspace. 
If the on-stack CS had changed before nested event came and we didn't 
reset it, we could end up doing an iret with a hypercall iret, assuming 
we return to kernel with direct iret if on-stack CS is 0 (yet have to 
change it to 3 before doing so because guest kernel is in ring 3) and 
userspace with hypercall iret if 3 in x86 64bit. The scenario looks 
something like this:
 ...
 - enable events; in critical section: returning to kernel via direct 
iret (on-stack CS is 0);
 ...
 - orb   $3,1*8(%rsp): set on-stack CS to 3
 - nested event came: fixing up the stack frame;
 - go back to handle events; perform iret again; if we didn't reset 
on-stack CS to be 0 in fixup routine, we would return with a hypercall 
iret instead of a direct iret (assume if on-stack CS is 3, we return to 
userspace with hypercall iret)
In x86 64-bit mini-os, the critical section only gets executed iff 
events need to be enabled and we are returning to kernel. So does fixup 
routine. Thus it is safe to reset the lowest byte of CS to 0 in fixup 
routine.
It doesn't hurt not doing this. But I think conceptually the stack frame 
should be the same after fixing up. ;-)
Thanks,

--
xu

:q!


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel