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

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 10/02/12 10:21 PM >>>
>On Tue, Sep 04, 2012 at 10:26:18AM +0100, Jan Beulich wrote:
>> 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?

I think so (don't have the sources around at home to check), but that's
not the point. What absolutely has to happen is the _clearing_ of the
selector registers before switching descriptor tables (even if done via
multicall, as the hypervisor may restore guest state between any two
pieces of a multicall set).

Jan


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