Subject: Re: [vserver] VServer on armel architecture
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Fri, 19 Feb 2010 15:18:52 +0100

On Fri, Feb 19, 2010 at 12:41:09PM +0100, Jakob Lell wrote:
> Hi,

> I am trying to get vserver work on the armel architecture. The hardware 
> used is a Marvell SheevaPlug with Debian Squeeze.

> The first step was to compile the kernel. This only required adding one 
> missing "#include <linux/vs_memory.h>" to arch/arm/include/asm/tlb.h 
> after the line " #else /* !CONFIG_MMU */". With this small fix, the 
> kernel compiles and boots without any errors.

good, will add that to the next release

> The next thing to do is the userspace utility. The main problem here is 
> that the ABI for calling linux system calls has changed. I've attached a 
> patch which fixes this with an appropriate #ifdef. The program compiles 
> fine with this patch and system calls seem to work. Since dietlibc is 
> not yet working on armel, I had to compile util-vserver with glibc. I 
> could already create a new vserver using the following command (before 
> doing /etc/init.d/util-vserver start):

> vserver test build -m debootstrap --hostname test --rootdir /mnt/stick/ 
> --interface eth0:192.168.1.21/24 -- -d lenny

> However, starting the vserver using "vserver test start" fails with the 
> following error message:
> /proc/uptime can not be accessed. Usually, this is caused by
> procfs-security. Please read the FAQ for more details
> http://linux-vserver.org/Proc-Security

what util-vserver version?

> After running "/etc/init.d/util-vserver start", trying to start the 
> vserver using "vserver test start" fails with a different error message:
> vspace: clone(): No space left on device

> Here is the strace output line of the failing clone system call:
> clone(child_stack=0, flags=CLONE_VFORK|CLONE_NEWNS|SIGCHLD) = -1 ENOSPC 
> (No space left on device)

> Some debugging in /etc/init.d/util-vserver showed that this problem 
> occurs after running the mount_cgroup function. Have you got any hints 
> about how to resolve this problem?

hmm, cgroup support is working on that arch?
i.e. could you verify that with a vanilla kernel?

> I've now finally found a workaround: When running 
> "/etc/init.d/vprocunhide start" and not "/etc/init.d/util-vserver 
> start", it is possible to start and use the vserver. When doing so, the 
> clone system call works successfully even though it uses exactly the 
> same parameters as the failing call above:
> clone(child_stack=0, flags=CLONE_VFORK|CLONE_NEWNS|SIGCHLD) = 7149

looks like it works without the cgroup stuff ...
good work!

best,
Herbert

> Regards
> Jakob Lell
> 

> Index: lib/syscall-alternative.h
> ===================================================================
> --- lib/syscall-alternative.h	(revision 2877)
> +++ lib/syscall-alternative.h	(working copy)
> @@ -90,9 +90,35 @@
>  
>  #elif	defined(__arm__)
>  
> +#ifdef __ARM_EABI__
> +
>  /*	The Arm calling convention uses stack args after four arguments
>  	but the Linux kernel gets up to seven arguments in registers.
>  	
> +	scnr:	r7
> +	args:	a1(r0), a2(r1), a3(r2), a4(r3), a5(r4), a6(r5),
> +	sret:	r0(r0)
> +	serr:	(sret >= (unsigned)-EMAXERRNO)
> +	call:	swi
> +	clob:	memory
> +	move:	mov $dR,$sR
> +*/
> +
> +#define	__sysc_max_err	125
> +
> +#define	__sysc_cmd(n)	"swi $0x0"
> +
> +#define	__sysc_regs	"r0", "r1", "r2", "r3", "r4", "r5"
> +#define	__sysc_reg_cid	"r7"
> +#define	__sysc_reg_ret	"r0"
> +
> +#warning syscall arch armel not tested yet
> +
> +#else
> +
> +/*	The Arm calling convention uses stack args after four arguments
> +	but the Linux kernel gets up to seven arguments in registers.
> +	
>  	scnr:	imm
>  	args:	a1(r0), a2(r1), a3(r2), a4(r3), a5(r4), a6(r5),
>  	sret:	r0(r0)
> @@ -111,6 +137,7 @@
>  
>  #warning syscall arch arm not tested yet
>  
> +#endif
>  
>  
>  /*	*****************************************