Xen users - Jan 2006 - 64bit processors and TLS warning message

Hello,

	I am running an AMD64 Debian system and I noticed that the warning
message about /lib/tls like on my other 32bit systems does not appear on
this one. Does that mean that AM64 Linux archs aren''t TLS enabled ?


Regards,


Christophe Painchaud



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

> 	I am running an AMD64 Debian system and I noticed that the warning
> message about /lib/tls like on my other 32bit systems does not appear on
> this one. Does that mean that AM64 Linux archs aren''t TLS enabled
?
It''s just not an issue like it is on 32-bit - the TLS implementation
doesn''t
conflict with the way Xen enforces protection.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

Mark Williamson wrote:
> It''s just not an issue like it is on 32-bit - the TLS
implementation doesn''t
> conflict with the way Xen enforces protection.
Uhm.  Doh.
Why doesn''t the documentation mention this?

I would''ve gone a very different route with a Xen system I''ve
spent a
lot of time on had I known this.  *sigh*.

Could you elaborate a bit on the above?

Is the situation the same for all 64bit CPUs?

Could you please update:
http://wiki.xensource.com/xenwiki/XenSpecificGlibc
to mention that this hack is not necessary if you''re running
this-and-that CPU (the page is protected)?

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

> > It''s just not an issue like it is on 32-bit - the TLS
implementation
> > doesn''t conflict with the way Xen enforces protection.
>
> Uhm.  Doh.
> Why doesn''t the documentation mention this?
I guess nobody thought of it before: the documentation is i386 oriented 
because that''s what we''ve had for longest.  The information in
there is
common to x86_64, but doesn''t go into the differences.
> I would''ve gone a very different route with a Xen system
I''ve spent a
> lot of time on had I known this.  *sigh*.
Oops.  Sorry.
> Could you elaborate a bit on the above?
Xen protects itself using x86 segmentation.  This is because the page-tables 
alone only make a distinction between user / supervisor level, and we have 
three privilege levels to maintain: user / supervisor / hypervisor.  The 
default TLS implementation in glibc does something *very strange* with 
segments, that one wouldn''t expect to be possible at all, as a
performance
optimisation. (side note: I recently talked this over with people locally, 
trying to get this straight once and for all - my mind boggled, it''s
such a
weird trick!!!)

Unfortunately, this performance optimisation cannot be allowed to be used 
directly under Xen, since it would violate security properties of the system.  
Xen *can* emulate the correct behaviour but this is pretty slow; hence the 
suggestion that people disable the TLS library.  Lots of distros are now 
including a libc that is (one way or another) friendly towards Xen (by having 
an option not to use the negative segment offset tricks on Xen, or just not 
including them at all).

On x86_64 (and other architectures) it''s not necessary to protect Xen
using
segmentation, so we don''t really need to care what the OS actually does
with
segmentation - even if the OS does setup weird and wonderful segments, they 
can''t violate our security properties.  Hence the segmentation tricks
will
work fine on your 64-bit box, without the slowdown incurred by emulation.
> Is the situation the same for all 64bit CPUs?
I doubt anything but x86 abuses segments in such interesting / disturbing 
ways ;-)  So yes, they should be OK.
> Could you please update:
> http://wiki.xensource.com/xenwiki/XenSpecificGlibc
> to mention that this hack is not necessary if you''re running
> this-and-that CPU (the page is protected)?
Do you have an account?  The vast majority of pages are editable by all, but 
they do require sign-up - anonymous editting easily results in an 
unmanageable amount of spam, unless you''re big enough (like Wikipedia)
to
clean up quickly.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

Mark Williamson wrote:
> > I would''ve gone a very different route with a Xen system
I''ve spent a
> > lot of time on had I known this.  *sigh*.
>
> Oops.  Sorry.
Not your fault.  I live, I learn :-).
> > Could you elaborate a bit on the above?
[snip elaboration]
Thanks for the well-written explanation!
> > Could you please update:
> > http://wiki.xensource.com/xenwiki/XenSpecificGlibc
>
> Do you have an account?
No.
> The vast majority of pages are editable by all, but
> they do require sign-up
I''ll go sign up.

I''ll try adding an i386 keyword to some of these pages:
http://wiki.xensource.com/xenwiki/FindPage?action=fullsearch&value=XenSpecificGlibc

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

Mark Williamson wrote:
> PAINCHAUD Christophe:
> > I am running an AMD64 Debian system and I noticed that the warning
> > message about /lib/tls like on my other 32bit systems does not appear
on
> > this one. Does that mean that AM64 Linux archs aren''t TLS
enabled ?
>
> It''s just not an issue like it is on 32-bit - the TLS
implementation doesn''t
> conflict with the way Xen enforces protection.
If by "different implementation" you mean that "different TLS
implementations in Xen are used for different hardware architecures",
that makes me wonder:

If I do *not* use -mno-tls-direct-seg-refs or gcc patches on my x86-64
system, will I actually enjoy a performance benefit from the GCC
compiler''s TLS optimizations, at least for 32bit userland apps?

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

> > > I am running an AMD64 Debian system and I noticed that the
warning
> > > message about /lib/tls like on my other 32bit systems does not
appear
> > > on this one. Does that mean that AM64 Linux archs aren''t
TLS enabled ?
> >
> > It''s just not an issue like it is on 32-bit - the TLS
implementation
> > doesn''t conflict with the way Xen enforces protection.
>
> If by "different implementation" you mean that "different
TLS
> implementations in Xen are used for different hardware architecures",
> that makes me wonder:
I rather suspected they might have implemented glibc''s TLS support in a
slightly more conventional way on x86_64 (i.e. not using the cunning segment 
trick).  This is apparently not the case, so the only difference is in the 
way Xen protects itself from the guest.  It''s still the case that
glibc''s TLS
on x86-64 should be perfectly safe and performant under Xen.
> If I do *not* use -mno-tls-direct-seg-refs or gcc patches on my x86-64
> system, will I actually enjoy a performance benefit from the GCC
> compiler''s TLS optimizations, at least for 32bit userland apps?
In theory, yes, this might speed things up since it''ll improve the
efficiency
of access to TLS data.  In practice, it''s likely to be difficult or 
impossible to measure the speedup for many apps (on x86-32, SuSE don''t
ship
code that uses direct seg refs because they measured negligible 
improvements).

There shouldn''t be any performance harm in allowing direct seg refs on
x86-64,
though, since they don''t need to be emulated as they do on x86-32.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

> > Oops.  Sorry.
>
> Not your fault.  I live, I learn :-).
>
> > > Could you elaborate a bit on the above?
>
> [snip elaboration]
> Thanks for the well-written explanation!
Thanks ;-)  Some credit should go to Steven Smith / Michael Fetterman for 
*finally* helping me understand the issues involved (it''s something
I''d never
quite delved deeply enough into in order to understand *what* glibc was 
trying to do).
> > The vast majority of pages are editable by all, but
> > they do require sign-up
>
> I''ll go sign up.
>
> I''ll try adding an i386 keyword to some of these pages:
>
http://wiki.xensource.com/xenwiki/FindPage?action=fullsearch&value=XenSpeci
>ficGlibc
Thanks, that''d probably be rather useful.

You might also like to look at the segmentation explanation linked from that 
page: it explains how the emulation works on 32-bit and why it is slow.

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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