From owner-freebsd-emulation@FreeBSD.ORG Mon Jul 19 17:36:25 2010 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 8BD31106566B; Mon, 19 Jul 2010 17:36:25 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 3AA8C8FC16; Mon, 19 Jul 2010 17:36:25 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 2E6FF1E00210; Mon, 19 Jul 2010 19:36:24 +0200 (CEST) Received: from triton8.kn-bremen.de (localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.3) with ESMTP id o6JHXcrW070007; Mon, 19 Jul 2010 19:33:38 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id o6JHXcSI070006; Mon, 19 Jul 2010 19:33:38 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Mon, 19 Jul 2010 19:33:37 +0200 To: Norikatsu Shigemura Message-ID: <20100719173337.GA68737@triton8.kn-bremen.de> References: <20100720013159.84a3cb86.nork@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100720013159.84a3cb86.nork@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Juergen Lock , freebsd-emulation@FreeBSD.org Subject: Re: [ports/emulators/qemu-devel] Fix BSD User space emulator issue 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: Mon, 19 Jul 2010 17:36:25 -0000 On Tue, Jul 20, 2010 at 01:31:59AM +0900, Norikatsu Shigemura wrote: > Hi nox. Hi! > > I found a minor issue on qemu-devel. We can't use BSD User space > emulator by default. Because default bsd-type is OpenBSD:-(. > > In this time, we run always qemu-* with -bsd freebsd option, like > qemu-x86_64 -bsd freebsd /bin/ls. But following patch fix default > behavior. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > --- bsd-user/main.c.orig 2010-05-05 00:27:48.000000000 +0900 > +++ bsd-user/main.c 2010-07-19 00:49:30.020088803 +0900 > @@ -740,7 +740,7 @@ > int gdbstub_port = 0; > char **target_environ, **wrk; > envlist_t *envlist = NULL; > - bsd_type = target_openbsd; > + bsd_type = target_freebsd; > > if (argc <= 1) > usage(); > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > BTW, do you have any idea to support ARM? > > And, JFYI, I tried to test sparc64, i386, x86_64 on FreeBSD/amd64. > But I confirmed that x86_64 is only OK like following: > > $ qemu-x86_64 -bsd freebsd /rescue/ls -lF / > -r--r--r-- 1 root wheel 6196 Jan 3 2010 COPYRIGHT > drwxr-xr-x 2 root wheel 47 Jul 18 01:49 bin/ > drwxr-xr-x 9 root wheel 36 Jul 18 01:49 boot/ > : > > $ make world TARGET_ARCH=sparc64 DESTDIR=/tmp/sparc64 > $ qemu-sparc64 -bsd freebsd -L /tmp/sparc64 /tmp/sparc64/rescue/ls -lF / > (in this case, qemu-sparc64 is cpu eater.) I'm indifferent as to whether we should change the default for -bsd, maybe we should... But before worrying about that I think the userspace emulation needs to work better, like there are still a lot of syscalls that need to be handled properly at the very least, before that is done emulating diffent archs than the host can't really work well enough to be useful. And about arm, I think all that's needed is someone to do the work... (Just like adding the missing syscall handling etc to get the other bsd-user targets working.) Cheers, Juergen PS: As an example what is to do wrt syscalls, here is one of my bsd-user updates that got committed to qemu upstream a while ago: http://git.savannah.gnu.org/cgit/qemu.git/commit/?id=78cfb07fe0dc556cae662a0fab5fe1bd33daabdb (the commitlog is incomplete since I forgot to submit one myself in the thread where I submitted the patch...) As you can see, syscall parameters may need to be converted to the target endianness/wordsize, memory they point to may need to be locked/unlocked... The good news is probably a lot of the missing code can be copied/adapted from the linux-user target like I did for e.g. TARGET_FREEBSD_NR_writev there.