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

[Keir Fraser <keir.xen@xxxxxxxxx>]

On 26/07/2011 20:08, "Andrew Lutomirski" <luto@xxxxxxx> wrote:

> 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.

Yes, that's right.

> 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.

Either that, or Linux needs to poke its preferred 32- or 64-bit user CS
value into the return stackframe when it receives a syscall notification
from Xen.

 -- Keir

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



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