[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] 64bit dom0, 32bit domU, glibc?


  • To: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
  • From: Nico Kadel-Garcia <nkadel@xxxxxxxxx>
  • Date: Thu, 23 Aug 2007 04:54:33 +0100
  • Cc: xen-users@xxxxxxxxxxxxxxxxxxx, Joseph Smith <smithj@xxxxxxxxx>
  • Delivery-date: Wed, 22 Aug 2007 20:54:11 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=K+ICajcZBBs4DzPoFGi5j0rrMoy+TsimoJSGVI1PJEa/MP0AyN3OLTSeUoq2CgK+c3sTT/ONEaQLbp0WHeSDTL7a5K55CmhH5lUEVh5nKpL8zkzBH1/gpjQfqiepEHHcR1vDzeTfd9LX3YTfBsrlwUGdhMAUpK4vh34NSvrHw+g=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

Mark Williamson wrote:
i'm using xen 3.1 and i have a 64bit dom0 and 32bit (PAE enabled) domUs
(32bit userland and kernels). Do I still need to replace glibc w/ one
compiled with -mno-tls-refs in the domUs? I don't get the warning about
glibc during the domU boots.

No, you don't need to do that.

The TLS refs problem happened because 32-bit Xen and glibc both want to do crazy things with the processor's segmentation hardware. 32-bit Xen needs the segmentation for its own protection.

64-bit Xen doesn't protect itself using segmentation, so it's not necessary to do anything to prevent a conflict with glibc.
That old problem also seemed to involve the libraries in /lib/tls. It was easy to just move them aside to /lib/tls.old, and current versions of RedHat kernels drop a little file called "kernelcap" in /etc/ld.so.conf.d/ that helps prevent the use of those libraries.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.