Re: [Xen-devel] Using debug-key 'o: Dump IOMMU p2m table, locks up machine

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Thursday, September 20, 2012, 10:08:45 AM, you wrote:

> Ping?

Perhaps changing the subject or starting a new thread altogether for this would 
provoke more reaction ?

>>>> On 04.09.12 at 11:26, Jan Beulich wrote:
>>>>> On 04.09.12 at 10:13, Sander Eikelenboom <linux@xxxxxxxxxxxxxx> wrote:
>> > Hmm don't know how to get the file/line, only thing i have found is:
>> > 
>> > serveerstertje:/boot# gdb xen-syms-4.2.0-rc4-pre
>> > GNU gdb (GDB) 7.0.1-debian
>> > Copyright (C) 2009 Free Software Foundation, Inc.
>> > License GPLv3+: GNU GPL version 3 or later 
>> > <http://gnu.org/licenses/gpl.html>
>> > This is free software: you are free to change and redistribute it.
>> > There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> > and "show warranty" for details.
>> > This GDB was configured as "x86_64-linux-gnu".
>> > For bug reporting instructions, please see:
>> > <http://www.gnu.org/software/gdb/bugs/>...
>> > Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done.
>> > (gdb) x/i 0xffff82c48015c9ee
>> > 0xffff82c48015c9ee <context_switch+916>:        mov    %edx,%gs
>> > (gdb)
>> 
>> I'm not really a gdb expert, so I don't know off the top of my
>> head either. I thought I said in a previous reply that people
>> generally appear to use the addr2line utility for that purpose.
>> 
>> But the disassembly already tells us where precisely the
>> problem is: The selector value (0x0063) attempted to be put
>> into %gs is apparently wrong in the context of the current
>> GDT. Now, that's GDT_ENTRY_TLS_MIN on the Linux side,
>> and ought to be valid. I'm surprised the guest (and the current
>> process in it) survives this (as the failure here results in a failsafe
>> callback into the guest).
>> 
>> Looking at the Linux side of things, this has been that way
>> forever, and I think has always been broken: On x86-64, it
>> should also clear %gs here (since 32-bit processes use it for
>> their TLS, and there's nothing wrong for a 64-bit process to put
>> something in there either), albeit not via loadsegment(), but
>> through xen_load_gs_index(). And I neither see why on 32-bit
>> it only clears %gs - %fs can as much hold a selector that might
>> get invalidated with the TLS descriptor updates. Eduardo,
>> Jeremy, Konrad?
>> 
>> Jan
>> 






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