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:09:07 -0400 Message-ID: <20121002200907.GC668@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> <5045E55A02000078000986E4@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <5045E55A02000078000986E4@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Jeremy Fitzhardinge , ehabkost@redhat.com, "xen-devel@lists.xen.org" , "wei.wang2@amd.com" , Sander Eikelenboom , Keir Fraser , Santosh Jodh List-Id: xen-devel@lists.xenproject.org On Tue, Sep 04, 2012 at 10:26:18AM +0100, 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? How is it on the SLES side? Do you set/restore all of the segment registers? > > Jan