From owner-freebsd-emulation@FreeBSD.ORG Tue Mar 20 20:32:26 2007 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7640116A400; Tue, 20 Mar 2007 20:32:26 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id ED3E313C45D; Tue, 20 Mar 2007 20:32:21 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l2KKWJrK098111; Tue, 20 Mar 2007 16:32:19 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Tijl Coosemans Date: Tue, 20 Mar 2007 16:32:15 -0400 User-Agent: KMail/1.6.2 References: <20070316120038.2iizia24mc4wcw8s@webmail.leidinger.net> <200703191618.14204.jkim@FreeBSD.org> <200703201440.06452.tijl@ulyssis.org> In-Reply-To: <200703201440.06452.tijl@ulyssis.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200703201632.16749.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.88.6/2881/Tue Mar 20 15:53:24 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Alexander Leidinger , freebsd-emulation@FreeBSD.org, kib@FreeBSD.org, rdivacky@FreeBSD.org Subject: Re: 2.6.16 for linuxulator & 7.0 release X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2007 20:32:26 -0000 On Tuesday 20 March 2007 09:40 am, Tijl Coosemans wrote: > On Monday 19 March 2007 21:18:11 Jung-uk Kim wrote: > > 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.i4GMhvhh0371 > > > >47 > > > > > > 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. > > Ok, that should work. The problem is that Wine currently makes some > assumptions about the use of %fs just like glibc does about %gs. > This is kind of the same problem you had when implementing linux > TLS on amd64. Wine could be patched to never write to %fs (and %gs) > and to make use of i386_set_fsbase() instead. Something to add to > my todo list... Yes, sysarch(2) should do. You should never rely on GDT entries for anything on amd64. Jung-uk Kim