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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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