Re: [PATCH] Qemu support for PPC

Re: [PATCH] Qemu support for PPC

[Rusty Russell]

In <20030407072144.A28096@infradead.org> you wrote:
> On Mon, Apr 07, 2003 at 03:09:37PM +1000, Paul Mackerras wrote:
> > Anyway, it's not your call.
> 
> if you look at MAINTAINERS I'm responsible for personality handling, so
> maybe it actually _is_ my call?

Which simply shows that an entry in the MAINTAINERS file does not a
maintainer make, since your first post showed such misundestanding of
what personalities do, and you've let the 2.4 and 2.5 personality
lists get out of sync.

Qemu could hack it into all the stat, stat64, open, chmod, chown,
link, rename etc. calls in the emulator, yes, but the in-kernel
solution already exists and is far simpler.

> Because stuff should go into 2.5 first.

I happens, though, whatever you may think.  It was done as a 2.4 patch
because there's a tighter time constraint on entry into 2.4.

> And even if it looks trivial there's an important policy decision
> here: do we want to clutter up our personality system for userspace
> emulators?  If you look at the current list of personalities they
> all have kernel implementations

This is not qemu specific, of course.  If you say it's not going in,
then I'll accept that and do the work inside qemu.  It'll be damn
slow, of course.

Thanks,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [PATCH] Qemu support for PPC

[Christoph Hellwig]

On Mon, Apr 07, 2003 at 04:45:33PM +1000, Rusty Russell wrote:
> Which simply shows that an entry in the MAINTAINERS file does not a
> maintainer make, since your first post showed such misundestanding of
> what personalities do,

oha,  just because I read the patch wrongly (I somehow though it added
a binary format)  I now don't understand the personalities at all?
Remember that I wrote most of the code that's now in kernel/exec_domain.c..

> and you've let the 2.4 and 2.5 personality
> lists get out of sync.

That's what's happening if people hack last minute changes into 2.4
instead of properly going through 2.5 and the maintainer.

> Qemu could hack it into all the stat, stat64, open, chmod, chown,
> link, rename etc. calls in the emulator, yes, but the in-kernel
> solution already exists and is far simpler.

The inkernel solution exists, and it's a bad (though valueable) hack.

> > Because stuff should go into 2.5 first.
> 
> I happens, though, whatever you may think.  It was done as a 2.4 patch
> because there's a tighter time constraint on entry into 2.4.

Umm, quemu exists for about two weeks now.  I think you're pressing
a bit too much.

Why is there a time constraint?  It worked for you up to now without
this patch in mainline and you can keep patching your trees for 2.4.21,
too.

> This is not qemu specific, of course.  If you say it's not going in,
> then I'll accept that and do the work inside qemu.  It'll be damn
> slow, of course.

Please try it in userspace first, if it's really not doable we can abuse
the kernel for it, but I'd prefer not doing it.  And if we need to do
it in the kernel we should think about a sys_altroot mechanism that doesn't
rely on the personality handling which isn't needed by qemu at all but
rather just exposes set_fs_altroot to userspace directly.  In fact that
sounds like a very good idea to start with.  What about hacking it up
for 2.5? :)

Re: [PATCH] Qemu support for PPC

[Rusty Russell]

In message <20030407075622.A28354@infradead.org> you write:
> On Mon, Apr 07, 2003 at 04:45:33PM +1000, Rusty Russell wrote:
> > Which simply shows that an entry in the MAINTAINERS file does not a
> > maintainer make, since your first post showed such misundestanding of
> > what personalities do,
> 
> oha,  just because I read the patch wrongly (I somehow though it added
> a binary format)

You didn't read the patch, but you said it was a bad idea.  Do you
wonder why people don't send patches through you? 8(

> I now don't understand the personalities at all?
> Remember that I wrote most of the code that's now in kernel/exec_domain.c..

Oh good: a serious question.  Why don't we drop the personality field
in struct task_struct and just use exec_domain?  Then the flags could
be unfolded from the personality number, and placed in a "flags"
element in struct exec_domain, the personality() macro would vanish,
the set_personality() macro would vanish, and things would be
generally clearer?

Perhaps there's some future aim you have in mind which conflicts with
this, or is it just a "not done yet".

> > I happens, though, whatever you may think.  It was done as a 2.4 patch
> > because there's a tighter time constraint on entry into 2.4.
> 
> Umm, quemu exists for about two weeks now.  I think you're pressing
> a bit too much.
> 
> Why is there a time constraint?  It worked for you up to now without
> this patch in mainline and you can keep patching your trees for 2.4.21,
> too.

That applies to any kernel mod, of course.  qemu is much more usable
(ie. it's sanely packagable) with this functionality, ie. it's pretty
much a requirement for increasing adoption.

> > This is not qemu specific, of course.  If you say it's not going in,
> > then I'll accept that and do the work inside qemu.  It'll be damn
> > slow, of course.
> 
> Please try it in userspace first, if it's really not doable we can abuse
> the kernel for it, but I'd prefer not doing it.  And if we need to do
> it in the kernel we should think about a sys_altroot mechanism that doesn't
> rely on the personality handling which isn't needed by qemu at all but
> rather just exposes set_fs_altroot to userspace directly.  In fact that
> sounds like a very good idea to start with.  What about hacking it up
> for 2.5? :)

I discussed this with Paul M, too.  You can do it *iff* you drop it on
exec, otherwise you get chroot-like security issues.

Cheers,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [PATCH] Qemu support for PPC

[Alan Cox]

On Llu, 2003-04-07 at 07:45, Rusty Russell wrote:
> I happens, though, whatever you may think.  It was done as a 2.4 patch
> because there's a tighter time constraint on entry into 2.4.

If it hasn't been generally accepted and cleaned up for 2.5 then it
shouldn't be going into 2.4

> This is not qemu specific, of course.  If you say it's not going in,
> then I'll accept that and do the work inside qemu.  It'll be damn
> slow, of course.

WTF should that make it slow ?

Re: [PATCH] Qemu support for PPC

[Christoph Hellwig]

On Mon, Apr 07, 2003 at 06:34:17PM +1000, Rusty Russell wrote:
> Oh good: a serious question.  Why don't we drop the personality field
> in struct task_struct and just use exec_domain?  Then the flags could
> be unfolded from the personality number, and placed in a "flags"
> element in struct exec_domain, the personality() macro would vanish,
> the set_personality() macro would vanish, and things would be
> generally clearer?

The personality number is exposed through sys_personality, so unfortunately
we can't get rid of it.  I still wonder what crack the person inviting this
scheme was smoking, though..

> That applies to any kernel mod, of course.  qemu is much more usable
> (ie. it's sanely packagable) with this functionality, ie. it's pretty
> much a requirement for increasing adoption.

You can just easily let it run in a chroot or separate namespace,
you just won't get second look semantics. (Personally I think that's
a benefit, but some people disagree with this).

Re: [PATCH] Qemu support for PPC

[Rusty Russell]

In message <20030407134954.A31558@infradead.org> you write:
> On Mon, Apr 07, 2003 at 06:34:17PM +1000, Rusty Russell wrote:
> > Oh good: a serious question.  Why don't we drop the personality field
> > in struct task_struct and just use exec_domain?  Then the flags could
> > be unfolded from the personality number, and placed in a "flags"
> > element in struct exec_domain, the personality() macro would vanish,
> > the set_personality() macro would vanish, and things would be
> > generally clearer?
> 
> The personality number is exposed through sys_personality, so unfortunately
> we can't get rid of it.  I still wonder what crack the person inviting this
> scheme was smoking, though..

Yes.  It's a PITA that the bottom 8 bits map to exec_domain, and the
rest are random flags.  If each different personality mapped to a
separate exec_domain, the flags could be moved to the exec_domain
struct and it'd be far more logical.  But as you say, this would break
userspace which expects to be able to set the exec_domain and the
flags separately 8(.

BTW, there's a module refcount leak here:

int
__set_personality(u_long personality)
{
	struct exec_domain	*ep, *oep;

	ep = lookup_exec_domain(personality);
	if (ep == current_thread_info()->exec_domain) {
		current->personality = personality;
		return 0;
	}

You need "module_put(ep->owner)", since lookup_exec_domain bumps the
refcount.


> > That applies to any kernel mod, of course.  qemu is much more usable
> > (ie. it's sanely packagable) with this functionality, ie. it's pretty
> > much a requirement for increasing adoption.
> 
> You can just easily let it run in a chroot or separate namespace,
> you just won't get second look semantics. (Personally I think that's
> a benefit, but some people disagree with this).

No, then you can't access your files, which is unacceptable for many
users.

I've done the userspace implementation: I'll see if Fabrice chokes on
the speed hit.

Cheers,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [PATCH] Qemu support for PPC

[Rusty Russell]

In message <1049714507.2967.29.camel@dhcp22.swansea.linux.org.uk> you write:
> > This is not qemu specific, of course.  If you say it's not going in,
> > then I'll accept that and do the work inside qemu.  It'll be damn
> > slow, of course.
> 
> WTF should that make it slow ?

Well, there are two obvious methods.  The first, which I've
implemented, builds a tree at start time, which assumes things stay
static, but has significant startup overhead.

The fully dynamic solution (which personality + emul_prefix gives you
at the moment) means that you double every open, every stat, quadruple
every readlink, etc.  Of course, remember to handle relative paths (my
current code punts on this in the hope that noone will notice: we'll
see).

Unfortunately, it's not just /lib and /usr/lib, there's
/var/run/.nscd_socket which doesn't seem to like speaking wrong
endian.

Hey, I'd *love* read-only union mounts which can be done by non-root
(and obviously don't survive exec), but AFAICT noone but Al can write
one acceptable to the VFS maintainer 8).

Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: [PATCH] Qemu support for PPC

[Tom Rini]

On Mon, Apr 07, 2003 at 12:40:38PM +1000, Rusty Russell wrote:

> Paul, is this OK?
> 
> I'd like it in 2.4.21 if possible.
[snip]
> diff -urpN --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.4.21-pre6/arch/ppc/config.in working-2.4.21-pre6-wagner/arch/ppc/config.in
> --- linux-2.4.21-pre6/arch/ppc/config.in	2003-03-27 12:10:49.000000000 +1100
> +++ working-2.4.21-pre6-wagner/arch/ppc/config.in	2003-04-04 17:11:48.000000000 +1000
> @@ -183,6 +183,7 @@ fi
>  define_bool CONFIG_BINFMT_ELF y
>  define_bool CONFIG_KERNEL_ELF y
>  tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC
> +dep_tristate 'Kernel support for Linux/Intel ELF binaries' CONFIG_X86_EMU
>  
>  source drivers/pci/Config.in
>  

dep_tristate on what? :)

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: [PATCH] Qemu support for PPC

[Alan Cox]

On Llu, 2003-04-07 at 07:05, Paul Mackerras wrote:
> Well, all we really want is a way to set emul_prefix.  Which I could
> do with a PPC-specific syscall if I had to, I guess.  Doing it in
> userspace is possible but ugly, because you have to handle several
> different syscalls, plus keep track of the current directory, plus
> handle symlinks, etc., etc., in the emulator.  The kernel has all that
> information readily to hand plus the data structures to keep track of
> it all.

Why do you need emul_prefix in the first place ? You need a different
/lib for emulated binaries then use all the nice stuff Al has done
and mount yourself a file system that is in your namespace but not
the global one.

If you want to do overlaying then lets get the union fs for read only
stuff into the kernel properly and solve the -real- problem not hack
up some emulator magic again.

Re: [PATCH] Qemu support for PPC

[Christoph Hellwig]

On Mon, Apr 07, 2003 at 03:09:37PM +1000, Paul Mackerras wrote:
> sys_personality will fail if there isn't an exec_domain registered for
> the personality you want.

But there already is one registered :)  Okay, you\re right.

> Why?  It's a well-contained patch that affects very little outside its
> own area, and is quite similar to other things that have been there
> for ages.

Because stuff should go into 2.5 first.    And even if it looks trivial
there's an important policy decision here:  do we want to clutter up
our personality system for userspace emulators?   If you look at the
current list of personalities they all have kernel implementations, even
if not all of them are currently merged, qemu OTOH is a purely userspace
thing (and still very new!).  Personally I'd rather prefer qemu doing
pathname translation in userspace instead of bloating the kernel.  This
gets even more important when we get qemu-style emulators for other
architectures - the number of personalities needed just for this ugly
pathname-translation scheme will get very high.

> Anyway, it's not your call.

if you look at MAINTAINERS I'm responsible for personality handling, so
maybe it actually _is_ my call?

Re: [PATCH] Qemu support for PPC

[Paul Mackerras]

Christoph Hellwig writes:

> On Mon, Apr 07, 2003 at 03:09:37PM +1000, Paul Mackerras wrote:
> > sys_personality will fail if there isn't an exec_domain registered for
> > the personality you want.
> 
> But there already is one registered :)  Okay, you\re right.
> 
> > Why?  It's a well-contained patch that affects very little outside its
> > own area, and is quite similar to other things that have been there
> > for ages.
> 
> Because stuff should go into 2.5 first.    And even if it looks trivial
> there's an important policy decision here:  do we want to clutter up
> our personality system for userspace emulators?   If you look at the
> current list of personalities they all have kernel implementations, even
> if not all of them are currently merged, qemu OTOH is a purely userspace
> thing (and still very new!).  Personally I'd rather prefer qemu doing
> pathname translation in userspace instead of bloating the kernel.  This
> gets even more important when we get qemu-style emulators for other
> architectures - the number of personalities needed just for this ugly
> pathname-translation scheme will get very high.

Well, all we really want is a way to set emul_prefix.  Which I could
do with a PPC-specific syscall if I had to, I guess.  Doing it in
userspace is possible but ugly, because you have to handle several
different syscalls, plus keep track of the current directory, plus
handle symlinks, etc., etc., in the emulator.  The kernel has all that
information readily to hand plus the data structures to keep track of
it all.

> > Anyway, it's not your call.
> 
> if you look at MAINTAINERS I'm responsible for personality handling, so
> maybe it actually _is_ my call?

Oh.  Ah.  I didn't realize it was a subsystem with a maintainer.

Paul.

Re: [PATCH] Qemu support for PPC

[Christoph Hellwig]

On Mon, Apr 07, 2003 at 12:40:38PM +1000, Rusty Russell wrote:
> Paul, is this OK?
> 
> I'd like it in 2.4.21 if possible.

Please use sys_personality from userland.  And not, I don't think it should
go into 2.4.21.  Get it into 2.5 first.

Re: [PATCH] Qemu support for PPC

[Paul Mackerras]

Christoph Hellwig writes:

> On Mon, Apr 07, 2003 at 12:40:38PM +1000, Rusty Russell wrote:
> > Paul, is this OK?
> > 
> > I'd like it in 2.4.21 if possible.
> 
> Please use sys_personality from userland. 

sys_personality will fail if there isn't an exec_domain registered for
the personality you want.  The *whole* *point* of Rusty's patch is to
add an execution domain for x86 emulation so we *can* do sys_personality.

Did you actually look at the patch, or was your mail just a knee-jerk?

> And not, I don't think it should
> go into 2.4.21.  Get it into 2.5 first.

Why?  It's a well-contained patch that affects very little outside its
own area, and is quite similar to other things that have been there
for ages.  Anyway, it's not your call.

Paul.

[PATCH] Qemu support for PPC

[Rusty Russell]

Paul, is this OK?

I'd like it in 2.4.21 if possible.

Thanks,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Name: Qemu Kernel Patch for PPC
Author: Rusty Russell
Status: Tested on 2.4.21-pre6

D: Allow (0.1.5 or above) qemu to set the personality for emulation,
D: so files in /usr/gnemul/x86-linux get looked up before normal files
D: (this is the standard way of hooking in emulation libraries, etc).

diff -urpN --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.4.21-pre6/Documentation/Configure.help working-2.4.21-pre6-wagner/Documentation/Configure.help
--- linux-2.4.21-pre6/Documentation/Configure.help	2003-03-27 12:10:45.000000000 +1100
+++ working-2.4.21-pre6-wagner/Documentation/Configure.help	2003-04-04 17:15:21.000000000 +1000
@@ -4123,6 +4123,19 @@ CONFIG_BINFMT_JAVA
   binaries directly.  Note: this option is obsolete and scheduled for
   removal, use CONFIG_BINFMT_MISC instead.
 
+Kernel support for Linux/Intel ELF binaries
+CONFIG_X86_EMU
+  Say Y here if you want to be able to execute Linux/Intel ELF
+  binaries just like native binaries on your PPC machine. For
+  this to work, you need to have /usr/gnemul/x86-linux populated
+  with Intel libraries. etc.
+
+  You may answer M to compile the emulation support as a module and
+  later load the module when you want to use a Linux/Intel binary. The
+  module will be called x86emu.o.  If unsure, say Y.
+
 Solaris binary emulation
 CONFIG_SOLARIS_EMUL
   This is experimental code which will enable you to run (many)
diff -urpN --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.4.21-pre6/arch/ppc/config.in working-2.4.21-pre6-wagner/arch/ppc/config.in
--- linux-2.4.21-pre6/arch/ppc/config.in	2003-03-27 12:10:49.000000000 +1100
+++ working-2.4.21-pre6-wagner/arch/ppc/config.in	2003-04-04 17:11:48.000000000 +1000
@@ -183,6 +183,7 @@ fi
 define_bool CONFIG_BINFMT_ELF y
 define_bool CONFIG_KERNEL_ELF y
 tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC
+dep_tristate 'Kernel support for Linux/Intel ELF binaries' CONFIG_X86_EMU
 
 source drivers/pci/Config.in
 
diff -urpN --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.4.21-pre6/arch/ppc/kernel/Makefile working-2.4.21-pre6-wagner/arch/ppc/kernel/Makefile
--- linux-2.4.21-pre6/arch/ppc/kernel/Makefile	2003-03-27 12:10:49.000000000 +1100
+++ working-2.4.21-pre6-wagner/arch/ppc/kernel/Makefile	2003-04-04 17:11:16.000000000 +1000
@@ -66,6 +66,7 @@ obj-$(CONFIG_PAL4)		+= indirect_pci.o pc
 obj-$(CONFIG_SPRUCE)		+= indirect_pci.o pci_auto.o todc_time.o
 obj-$(CONFIG_8260)		+= m8260_setup.o ppc8260_pic.o
 obj-$(CONFIG_BOOTX_TEXT)	+= btext.o
+obj-$(CONFIG_X86_EMU)		+= x86emu.o
 
 include $(TOPDIR)/Rules.make
 
diff -urpN --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.4.21-pre6/arch/ppc/kernel/x86emu.c working-2.4.21-pre6-wagner/arch/ppc/kernel/x86emu.c
--- linux-2.4.21-pre6/arch/ppc/kernel/x86emu.c	1970-01-01 10:00:00.000000000 +1000
+++ working-2.4.21-pre6-wagner/arch/ppc/kernel/x86emu.c	2003-04-07 11:44:44.000000000 +1000
@@ -0,0 +1,29 @@
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/personality.h>
+#include <linux/binfmts.h>
+
+struct exec_domain x86_linux_exec_domain = {
+	.name		="X86LINUX",
+	.pers_low	= PER_X86_LINUX & PER_MASK,
+	.pers_high	= PER_X86_LINUX & PER_MASK,
+	.module		= THIS_MODULE
+};
+
+static int init(void)
+{
+	return register_exec_domain(&x86_linux_exec_domain);
+}
+
+static void fini(void)
+{
+	unregister_exec_domain(&x86_linux_exec_domain);
+}
+
+module_init(init);
+module_exit(fini);
+
+MODULE_DESCRIPTION("x86 Linux execution domain");
+MODULE_LICENSE("GPL");
diff -urpN --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.4.21-pre6/include/asm-ppc/namei.h working-2.4.21-pre6-wagner/include/asm-ppc/namei.h
--- linux-2.4.21-pre6/include/asm-ppc/namei.h	2003-03-27 12:11:03.000000000 +1100
+++ working-2.4.21-pre6-wagner/include/asm-ppc/namei.h	2003-04-04 15:15:12.000000000 +1000
@@ -8,12 +8,15 @@
 #ifndef __PPC_NAMEI_H
 #define __PPC_NAMEI_H
 
-/* This dummy routine maybe changed to something useful
- * for /usr/gnemul/ emulation stuff.
- * Look at asm-sparc/namei.h for details.
- */
-
-#define __emul_prefix() NULL
+static inline char *__emul_prefix(void)
+{
+	switch (current->personality) {
+	case (PER_X86_LINUX & PER_MASK):
+		return "usr/gnemul/x86-linux/";
+	default:
+		return NULL;
+	}
+}
 
 #endif /* __PPC_NAMEI_H */
 #endif /* __KERNEL__ */
diff -urpN --exclude TAGS -X /home/rusty/current-dontdiff --minimal linux-2.4.21-pre6/include/linux/personality.h working-2.4.21-pre6-wagner/include/linux/personality.h
--- linux-2.4.21-pre6/include/linux/personality.h	2003-03-18 04:59:22.000000000 +1100
+++ working-2.4.21-pre6-wagner/include/linux/personality.h	2003-04-04 12:14:09.000000000 +1000
@@ -64,6 +64,7 @@ enum {
 	PER_UW7 =		0x000e | STICKY_TIMEOUTS | MMAP_PAGE_ZERO,
 	PER_HPUX =		0x000f,
 	PER_OSF4 =		0x0010,			 /* OSF/1 v4 */
+	PER_X86_LINUX =		0x0011 | ADDR_LIMIT_32BIT,/* QEMU */
 	PER_MASK =		0x00ff,
 };
 

Re: [PATCH] Qemu support for PPC

[Paul Mackerras]

Rusty Russell writes:

> Paul, is this OK?
> 
> I'd like it in 2.4.21 if possible.

Looks good, I'd like it too.

Just one comment: 

> +Kernel support for Linux/Intel ELF binaries
> +CONFIG_X86_EMU
> +  Say Y here if you want to be able to execute Linux/Intel ELF
> +  binaries just like native binaries on your PPC machine. For
> +  this to work, you need to have /usr/gnemul/x86-linux populated
> +  with Intel libraries. etc.
> +
> +  You may answer M to compile the emulation support as a module and
> +  later load the module when you want to use a Linux/Intel binary. The
> +  module will be called x86emu.o.  If unsure, say Y.
> +

This should say that you need qemu as well, and it should probably
include the URL to Fabrice's qemu web page.

Paul.