[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Tue, Jul 26, 2011 at 4:48 PM, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> 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.

But it's still weird, because AFAICT xen_sysret64 already does the
right thing.  So presumably the failure case only happens when
something prevents sysret from working, like CONFIG_AUDITSYSCALL.

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

That sounds simpler.  It will also make Xen userspace look more like
native userspace.

--Andy

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.