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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Fri, Sep 28, 2012 at 02:26:58PM -0700, Jeremy Fitzhardinge wrote:
> On 09/20/2012 01:08 AM, Jan Beulich wrote:
> > Ping?
> 
> I've been meaning to work up a reply, but I haven't had time to swap in
> all the context again.

You would remember most of it. Perhaps that was what was saved at that
point of time and we did not need to restore/save other registers?

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