From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: Using debug-key 'o: Dump IOMMU p2m table, locks up machine Date: Tue, 2 Oct 2012 16:08:37 -0400 Message-ID: <20121002200837.GB668@phenom.dumpdata.com> References: <7914B38A4445B34AA16EB9F1352942F1012F0F6F4B98@SJCPMAILBOX01.citrite.net> <40501859.20120902104331@eikelenboom.it> <5044849002000078000982EA@nat28.tlf.novell.com> <4610648186.20120904090841@eikelenboom.it> <5045CDF302000078000985FB@nat28.tlf.novell.com> <4710608674.20120904101330@eikelenboom.it> <505AEB2D020000780009C81F@nat28.tlf.novell.com> <50661622.5030302@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <50661622.5030302@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jeremy Fitzhardinge Cc: ehabkost@redhat.com, "xen-devel@lists.xen.org" , "wei.wang2@amd.com" , Sander Eikelenboom , Jan Beulich , Keir Fraser , Santosh Jodh List-Id: xen-devel@lists.xenproject.org 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 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 > >>> 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: > >>> ... > >>> Reading symbols from /boot/xen-syms-4.2.0-rc4-pre...done. > >>> (gdb) x/i 0xffff82c48015c9ee > >>> 0xffff82c48015c9ee : 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 > >> > > > >