From owner-freebsd-emulation@FreeBSD.ORG Wed Oct 10 14:38:03 2007 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2057916A419 for ; Wed, 10 Oct 2007 14:38:02 +0000 (UTC) (envelope-from mihai.dontu@gmail.com) Received: from mail.bitdefender.com (ns.bitdefender.com [217.156.83.1]) by mx1.freebsd.org (Postfix) with ESMTP id C5AE113C45D for ; Wed, 10 Oct 2007 14:37:59 +0000 (UTC) (envelope-from mihai.dontu@gmail.com) Received: (qmail 29772 invoked by uid 1010); 10 Oct 2007 17:11:18 +0300 Received: from ns.bitdefender.com (HELO mdontu-l.dsd.ro) (217.156.83.1) by mail.bitdefender.com with AES256-SHA encrypted SMTP; 10 Oct 2007 17:11:17 +0300 From: Mihai =?utf-8?q?Don=C8=9Bu?= Organization: Home To: Tijl Coosemans Date: Wed, 10 Oct 2007 17:11:13 +0300 User-Agent: KMail/1.9.7 References: <200710082135.58099.mihai.dontu@gmail.com> <200710090348.52036.mihai.dontu@gmail.com> <200710101533.06287.tijl@ulyssis.org> In-Reply-To: <200710101533.06287.tijl@ulyssis.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200710101711.14386.mihai.dontu@gmail.com> X-BitDefender-Scanner: Clean, Agent: BitDefender qmail 2.0.0 on mail.bitdefender.com X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: v1, bayes score: 500, neunet score: 500, flags: [SUBJ_R_STOCK_0330_1; ], total: 0 Cc: freebsd-emulation@freebsd.org, freebsd-questions@freebsd.org, Jung-uk Kim Subject: Re: amd64_set_gsbase() 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: Wed, 10 Oct 2007 14:38:03 -0000 On Wednesday 10 October 2007, Tijl Coosemans wrote: > On Tuesday 09 October 2007 02:48:51 Mihai Donțu wrote: > > I have *one* more question: maybe I don't fully understand the hole > > BASE thing, but since the FreeBSD kernel does not preserve %gs and > > %fs, what is the purpose of amd64_set_XXbase()? > > The %fs, %gs registers and fsbase and gsbase MSRs are separate > registers. When you write %gs:offset, you actually get (gsbase+offset), > so the actual value of %gs doesn't matter. > > There are two ways to set gsbase. One is by using the privileged > instruction wrmsr to set gsbase directly (full 64bit base address), > which is what amd64_set_gsbase() exposes to userland. The other is by > loading a descriptor selector in %gs in which case gsbase will be set > to the base address (only 32bit base address) of a descriptor entry in > either the GDT or LDT. Invaluable info. Thanks! :) > To get back to what you are trying to do, because %gs isn't preserved, > I think you should avoid writing to it and instead strictly use > amd64_set_gsbase(). But from what you've written, I'm guessing you're > already doing this, so the next thing to try is to create threads with > PTHREAD_SCOPE_SYSTEM or use libthr instead of libpthread, because if > I'm not mistaken, PTHREAD_SCOPE_PROCESS in libpthread doesn't preserve > gsbase either. Well, I'm am not setting (loading) %gs, I *only* do amd64_set_gsbase() and expect that *all* instructions such as: mov %gs:0x10,%rax to be valid (not segfault). I don't really care what the value of %gs is as long as *all* the instructions as the above work and access the memory specified in amd64_set_gsbase( addr ). I was under the (wrong) impression that the value of %gs is important, that's why I wanted it preserved, but if you say: > [...] When you write %gs:offset, you actually get (gsbase+offset), > so the actual value of %gs doesn't matter. then I don't care if %gs' value gets lost over context switches as long as mov %gs:0x10,%rax and other such instructions, work. However, it turns out that amd64_set_gsbase() is not enough :( Either: a) someone *does* set %gs (and is not me); b) the 'gsbase' gets lost; The thing is I've ported my emulator to Linux and there I use modify_ldt() and then some __asm__ voodoo to load %gs, because (quote from man): - "ARCH_SET_GS is disabled in some kernels." - "Context switches for 64-bit segment bases are rather expensive. It may be a faster alternative to set a 32-bit base using a segment selector by setting up an LDT with modify_ldt(2) [...]" Anyhoo, I'll try to use 'libthr' and see if this helps. Thanks, again! -- Mihai Donțu