Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Mar 2007 16:18:11 -0400
From:      Jung-uk Kim <jkim@FreeBSD.org>
To:        freebsd-emulation@FreeBSD.org
Cc:        rdivacky@FreeBSD.org, kib@FreeBSD.org, Alexander Leidinger <Alexander@leidinger.net>
Subject:   Re: 2.6.16 for linuxulator & 7.0 release
Message-ID:  <200703191618.14204.jkim@FreeBSD.org>
In-Reply-To: <200703191819.31766.tijl@ulyssis.org>
References:  <20070316120038.2iizia24mc4wcw8s@webmail.leidinger.net> <200703191213.31197.jkim@FreeBSD.org> <200703191819.31766.tijl@ulyssis.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 19 March 2007 01:19 pm, Tijl Coosemans wrote:
> On Monday 19 March 2007 17:13:28 Jung-uk Kim wrote:
> > On Saturday 17 March 2007 09:29 am, Tijl Coosemans wrote:
> > > On Friday 16 March 2007 12:00:38 Alexander Leidinger wrote:
> > > > In p4 we have the futex/TLS stuff for amd64 but because of
> > > > the futexes not completely right part it is not committed to
> > > > current yet. As we already have the futex and TLS stuff for
> > > > i386 on a similar level in current, I would say we should go
> > > > ahead and sync the amd64 stuff. It is not used by default, so
> > > > we don't break existing linux stuff and we get the benefit of
> > > > more people being able to have a look at it and play with it.
> > > > So what are your opinions, shall we give jkim@ the green
> > > > light to MFp4 the futex/TLS stuff?
> > >
> > > You should let an amd64 guru review the tls part in imho. I
> > > don't think you can remove these lines for instance: (from
> > > linuxolator-p4.diff)
> > >
> > > ---  sys/amd64/amd64/cpu_switch.S.orig
> > > +++  sys/amd64/amd64/cpu_switch.S
> > > @@ -104,11 +104,12 @@
> > >  	testl	$PCB_32BIT,PCB_FLAGS(%r8)
> > >  	jz	1f				/* no, skip over */
> > >
> > > -	/* Save segment selector numbers */
> > > -	movl	%ds,PCB_DS(%r8)
> > > -	movl	%es,PCB_ES(%r8)
> > > -	movl	%fs,PCB_FS(%r8)
> > > [...]
> > > -	/* Restore segment selector numbers */
> > > -	movl	PCB_DS(%r8),%ds
> > > -	movl	PCB_ES(%r8),%es
> > > -	movl	PCB_FS(%r8),%fs
> >
> > Actually it was dead code, i.e., PCB_32BIT flag was never set
> > from anywhere at all.  I believe it was part of peter's
> > experiment, which was never materialized:
> >
> > http://docs.freebsd.org/cgi/mid.cgi?200405162243.i4GMhvhh037147
>
> Ah, thanks for clearing this up. So if I understand this correctly,
> %fs is never preserved right? That's one big cause of trouble for
> win32 programs then.

Correct.  If you load %gs, %fs, or any other segment registers from 
user land (e.g., movw %eax, %gs) and use it (e.g., movw %gs:0, %eax), 
you are doomed.

> That log entry mentions to do it ``at user<->kernel transition'';
> that's where it happens in the i386 kernel. Those 3 segment
> registers are pushed on the stack there (in exception.s). Could
> something similar be done on amd64 then?

Yes, something similar can be done.  However, I believe peter chose 
different design, i.e., disregarding segment registers because amd64 
can do flat memory addressing, which significantly simplifies design.  
Only base addresses for %fs and %gs are preserved via MSR.  If you 
want to preserve this behavior and to support segment registers in 
compatibility mode, you cannot prevent significant context switching 
overhead.

Jung-uk Kim



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200703191618.14204.jkim>