[Xen-devel] [semi-urgent Xen CS question] Re: git commit 9fd67b4ed0714ab718f1f9bd14c344af336a6df7 (x86-64: Give vvars their own page) breaks Xen PV guests (64-bit).

[Andrew Lutomirski <luto@xxxxxxx>]

On Tue, Jul 26, 2011 at 11:32 AM, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx> wrote:
> On Mon, Jul 25, 2011 at 09:50:30PM -0400, Andrew Lutomirski wrote:
>> After staring at the Xen assembly code with vague comprehension, I
>> think I can sort of understand what's going on.
>
> Ok.
>>
>> Can you run this little program on a working kernel and tell me what
>> it says (built as 64-bit and as 32-bit (with -m32)):
>
> 32-bit:
> [konrad@f13-x86-build ~]$ ./check
> cs = 73
> [konrad@f13-x86-build ~]$ uname -a
> Linux f13-x86-build.dumpdata.com 3.0.0 #1 SMP PREEMPT Tue Jul 26 09:56:38 EDT 
> 2011 i686 i686 i386 GNU/Linux
>
>
> 64-bit:
>
> [konrad@f13-amd64-build ~]$ ./check
> cs = e033

My best guess is that each task starts out with standard __USER_CS,
but the code in write_stack_trampoline (in the hypervisor) tells the
kernel that CS is 0xe033 and then the next return to userspace makes
it true.

I'll hack up a patch to avoid the crash.  I'll feel better about it if
you or any of the Xen gurus can confirm that explanation.  If I'm
right, I need to check for both __USER_CS and FLAT_RING3_CS.

--Andy

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel