[uml-devel] UML on Alpha

[uml-devel] UML on Alpha

[Cameron Patrick]

Hi all,

I've been looking into porting User-Mode Linux to the alpha.  I've made
a start by copying the i386-specific bits into {sys,sysdep,etc}-alpha,
following the porting guide on u-m-l.sf.net (which is sadly out of
date), and generally hacking stuff so that it looked appropriate.
Large portions of the kernel now seem to compile :-D.

Anyway, now I come to this mailing list in search of some explanations
for How UML Works these days in those places where that web site bears
little correlation with reality and I've been unable to work things out
for myself.

- I'm having trouble getting my head around the relationship between
  the pt_regs, pt_regs_subarch, uml_pt_regs and sigcontext.  (i.e. what
  they contain and what they're used for.)

- WTF is happening in arch/um/kernel/frame.c:227 :
        setup_arch_frame_raw(&raw_si->common.arch,
                             ucontext->uc_mcontext.fpregs, raw_si->common.sr);
  I can't see how uc_mcontext (which is of type "struct sigcontext")
  contains an fpregs member on /any/ architecture, even i386.  gcc
  certainly thinks it doesn't have an fpregs member on alpha :(

- Probably a lot more, but I'll try to harass this list only after I've
  spent a while trying to work things out myself.

Some of the problems (and implicit i386-isms) that I've noticed in UML
already are:

- Alpha system calls don't just return one value, they return two.  A
  lot of system calls also seem to take advantage of this; e.g. there is
  no __NR_getpid or __NR_getppid, but instead a __NR_getxpid which
  returns both.

- Since Alpha is a 64-bit architecture, there are no *64 system calls
  either.  This also affects other parts of the kernel which use #if to
  check for Alpha/sparc64/S390/etc to determine whether or not we're on
  a 64-bit platform.  I've worked around this by adding a -D__um_alpha__
  to CFLAGS and changing some places which check for __alpha__ to also
  check for __um_alpha__.  This may not be the cleanest way to do things
  thought :(

- I've needed to add a couple of extra (Alpha-specific) "dummy" headers
  to include/asm-um which just include include their arch/*.h
  counterparts.

- I've also changed asm-um/elf.h to only define ELF_EXEC_PAGESIZE,
  ELF_CLASS and elf_check_arch if they aren't already defined in
  archparam.  In the case of Alpha, the page size is 8192 (not 4096)
  and ELF_CLASS is ELFCLASS64 (not ELFCLASS32).  Is there any reason why
  this weren't being defined in some arch-specific way to begin with?

- Also, why is elf_check_arch() defined to return (1) in elf.h, whereas
  'real' architectures actually check something here?  I think that this
  is a UML bug, as an i386 UML will attempt to run binaries compiled for
  other platforms.  e.g. on a real i386:

  $ file ./stack_test_alpha 
  ./stack_test_alpha: ELF 64-bit LSB executable, Alpha (unofficial), version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped
  $ ./stack_test_alpha 
  bash: ./stack_test_alpha: cannot execute binary file

  but a UML running on i386 looks like it's trying to execute it:
  $ file ./stack_test_alpha 
  ./stack_test_alpha: ELF 64-bit LSB executable, Alpha (unofficial), version 1 (SYSV), dynamically linked (uses shared libs), not stripped
  $ ./stack_test_alpha 
  bash: ./stack_test_alpha: Cannot allocate memory

Another thing that would make life a lot easier would be being able to
cross-compile UML.  Unfortunately that would mean some way of getting
rid of mk_sc/mk_thread/mk_kern/etc, and I'm not sure what the best
approach to doing that would be :-/

Cheers,

Cameron.



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML on Alpha

[Jeff Dike]

On Sat, Dec 20, 2003 at 01:20:32PM +0800, Cameron Patrick wrote:
> - I'm having trouble getting my head around the relationship between
>   the pt_regs, pt_regs_subarch, uml_pt_regs and sigcontext.  (i.e. what
>   they contain and what they're used for.)

pt_regs is the UML version of the processor state.  It contains, among other
things, the register state of the process as either a sigcontext * (in tt mode)
or an array (in skas mode).  uml_pt_regs is the same thing, basically, except
that it can be used by the userspace portions of UML, while pt_regs can only
be used by the kernel portions of UML since it is defined in a kernel header.

In tt mode, the process register state is stored at the top of the kernel
stack in a struct sigcontext by the host kernel's signal delivery code.
Anything which manipulates the registers will, in tt mode, refer to that
structure through the pointer in the process' pt_regs.

pt_regs_subarch is the pt_regs of the underlying architecture.

> 
> - WTF is happening in arch/um/kernel/frame.c:227 :
>         setup_arch_frame_raw(&raw_si->common.arch,
>                              ucontext->uc_mcontext.fpregs, raw_si->common.sr);
>   I can't see how uc_mcontext (which is of type "struct sigcontext")
>   contains an fpregs member on /any/ architecture, even i386.  gcc
>   certainly thinks it doesn't have an fpregs member on alpha :(

From /usr/include/asm/sigcontext.h on my laptop:

struct sigcontext {
	...
        struct _fpstate * fpstate;
	...
};

> - Alpha system calls don't just return one value, they return two.  A
>   lot of system calls also seem to take advantage of this; e.g. there is
>   no __NR_getpid or __NR_getppid, but instead a __NR_getxpid which
>   returns both.

There should be enough flexibility in the EXECUTE_SYSCALL macro to let you
handle this.  If not, then just mash something in for Alpha, and we'll
clean it up later.

> 
> - Since Alpha is a 64-bit architecture, there are no *64 system calls
>   either.  This also affects other parts of the kernel which use #if to
>   check for Alpha/sparc64/S390/etc to determine whether or not we're on
>   a 64-bit platform.  I've worked around this by adding a -D__um_alpha__
>   to CFLAGS and changing some places which check for __alpha__ to also
>   check for __um_alpha__.  This may not be the cleanest way to do things
>   thought :(

This is a problem.  There should be a CONFIG_64BITS which all the 64 bit
arches set, so we don't have to add #ifdef UML && UML_ALPHA to all these
places.

> 
> - I've needed to add a couple of extra (Alpha-specific) "dummy" headers
>   to include/asm-um which just include include their arch/*.h
>   counterparts.

Fine, we can figure out whether this needs fixing later.

> - I've also changed asm-um/elf.h to only define ELF_EXEC_PAGESIZE,
>   ELF_CLASS and elf_check_arch if they aren't already defined in
>   archparam.  In the case of Alpha, the page size is 8192 (not 4096)
>   and ELF_CLASS is ELFCLASS64 (not ELFCLASS32).  Is there any reason why
>   this weren't being defined in some arch-specific way to begin with?

They should have been.  Feel free to send in cleanups like that as you go.

> - Also, why is elf_check_arch() defined to return (1) in elf.h, whereas
>   'real' architectures actually check something here?  I think that this
>   is a UML bug, as an i386 UML will attempt to run binaries compiled for
>   other platforms.  e.g. on a real i386:

Probably because I never bother figuring out what it was really supposed to
do.  I don't see any reason we can't just steal it from the underlying arch.

> Another thing that would make life a lot easier would be being able to
> cross-compile UML.  Unfortunately that would mean some way of getting
> rid of mk_sc/mk_thread/mk_kern/etc, and I'm not sure what the best
> approach to doing that would be :-/

There was a bit of work in that direction a while back.  What I think would
be a good way to go is to have a arch_headers rule in the Makefile, which
would execute on the target, and generate the headers.  They would land
in a single directory, which you would then copy over to the build box.
The build there would use those headers, or generate them itself if they
weren't present.

				Jeff


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML on Alpha

[BlaisorBlade]

Alle 06:20, sabato 20 dicembre 2003, Cameron Patrick ha scritto:
> Hi all,
>
> I've been looking into porting User-Mode Linux to the alpha.  I've made
> a start by copying the i386-specific bits into {sys,sysdep,etc}-alpha,
> following the porting guide on u-m-l.sf.net (which is sadly out of
> date), and generally hacking stuff so that it looked appropriate.
> Large portions of the kernel now seem to compile :-D.

Are you working on 2.4 or 2.6? I'd suggest the second choice, since otherwise 
you'll have to duplicate part of the work(recheck patches...). It is true 
than 2.6 still waits for some patches applied to 2.4, so you may get some 
more troubles(module loading still doesn't work in the vanilla tree, but 
search in the archives a few days ago for an up-to-date patch I posted and 
disable MODVERSIONS). But by the time you finish the porting, I think(or 
hope) that development will have moved to 2.6.

Note: by "vanilla" I mean 2.6 + the 2.6 patch you find on the UML site; 2.6 
includes some bits of the UML arch, but it doesn't work and Linus refused 
patches, so it's confusing.
-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729
EOSIGN



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML on Alpha

[Cameron Patrick]

On Sun, Dec 21, 2003 at 04:44:38PM +0100, BlaisorBlade wrote:

| Are you working on 2.4 or 2.6? I'd suggest the second choice, since otherwise 
| you'll have to duplicate part of the work(recheck patches...). It is true 
| than 2.6 still waits for some patches applied to 2.4, so you may get some 
| more troubles(module loading still doesn't work in the vanilla tree, but 
| search in the archives a few days ago for an up-to-date patch I posted and 
| disable MODVERSIONS). But by the time you finish the porting, I think(or 
| hope) that development will have moved to 2.6.

I've been working on 2.4 so far.  I'm not running 2.6 on any machine at
all ATM, and from the sounds of this mailing list, you can't run a 2.6
UML on a 2.4 host?  Also, the Alpha is running Debian woody at the
moment, and I'm not sure how well that copes with a 2.6 kernel.

But thanks for the advice, and I will look at porting 2.6 since it would
probably be less painful in the long run.

Cameron.



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML on Alpha

[Cameron Patrick]

On Sat, Dec 20, 2003 at 12:32:49PM -0500, Jeff Dike wrote:
| >         setup_arch_frame_raw(&raw_si->common.arch,
| >                              ucontext->uc_mcontext.fpregs, raw_si->common.sr);
[...]
| 
| >From /usr/include/asm/sigcontext.h on my laptop:
| 
| struct sigcontext {
| 	...
|         struct _fpstate * fpstate;
| 	...
| };

Yeah, but that's fpstate, not fpregs.  Looking at it more closely, on
i386, uc_mcontext is /not/ of type sigcontext, but mcontext_t, which
includes an fpregs member.  On alpha, uc_mcontext is a sigcontext, and
it has a sc_fpregs member.  I'm not sure that that's the appropriate
thing to change it to though - I'll have to look to see exactly what
it's using it for.

| > - Since Alpha is a 64-bit architecture, there are no *64 system calls
| >   either.  This also affects other parts of the kernel which use #if to
| >   check for Alpha/sparc64/S390/etc to determine whether or not we're on
| >   a 64-bit platform.  I've worked around this by adding a -D__um_alpha__
| >   to CFLAGS and changing some places which check for __alpha__ to also
| >   check for __um_alpha__.  This may not be the cleanest way to do things
| >   thought :(
| 
| This is a problem.  There should be a CONFIG_64BITS which all the 64 bit
| arches set, so we don't have to add #ifdef UML && UML_ALPHA to all these
| places.

Okay.  It doesn't seem to be there in 2.4.x, but I'll have a look at 2.6
some time and see if that makes this problem disappear.

| > cross-compile UML.  Unfortunately that would mean some way of getting
| > rid of mk_sc/mk_thread/mk_kern/etc, and I'm not sure what the best
| > approach to doing that would be :-/
| 
| There was a bit of work in that direction a while back.  What I think would
| be a good way to go is to have a arch_headers rule in the Makefile, which
| would execute on the target, and generate the headers.  They would land
| in a single directory, which you would then copy over to the build box.
| The build there would use those headers, or generate them itself if they
| weren't present.

Yeah, that sounds sensible.  I'll have a shot at munging the Makefiles
to do just that. :-)

Cheers,

Cameron.



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML on Alpha

[Matt Zimmerman]

On Mon, Dec 22, 2003 at 12:15:23PM +0800, Cameron Patrick wrote:

> I've been working on 2.4 so far.  I'm not running 2.6 on any machine at
> all ATM, and from the sounds of this mailing list, you can't run a 2.6
> UML on a 2.4 host?  Also, the Alpha is running Debian woody at the
> moment, and I'm not sure how well that copes with a 2.6 kernel.

It requires that the usual handful of packages be updated (procps,
util-linux, module-init-tools/modutils, etc.).

-- 
 - mdz


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML on Alpha

[Jeff Dike]

On Mon, Dec 22, 2003 at 12:19:51PM +0800, Cameron Patrick wrote:
> Yeah, but that's fpstate, not fpregs.  

Oops, nevermind...

> Okay.  It doesn't seem to be there in 2.4.x, but I'll have a look at 2.6
> some time and see if that makes this problem disappear.

It's not there either.  I think for now, ifdef those things on something like 
CONFIG_64BIT_UML, and set that in your config.in.

				Jeff


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML on Alpha

[BlaisorBlade]

Alle 05:19, lunedì 22 dicembre 2003, Cameron Patrick ha scritto:

> Okay.  It doesn't seem to be there in 2.4.x, but I'll have a look at 2.6
> some time and see if that makes this problem disappear.
>
> | > cross-compile UML.  Unfortunately that would mean some way of getting
> | > rid of mk_sc/mk_thread/mk_kern/etc, and I'm not sure what the best
> | > approach to doing that would be :-/
> |
> | There was a bit of work in that direction a while back.  What I think
> | would be a good way to go is to have a arch_headers rule in the Makefile,
> | which would execute on the target, and generate the headers.  They would
> | land in a single directory, which you would then copy over to the build
> | box. The build there would use those headers, or generate them itself if
> | they weren't present.

Sorry, I'm giving a look here and it seems that the problem is just for 
mk_ptregs and mk_sc(since the others include the building kernel includes) 
and that they need only the target headers; this could maybe be accomplished 
just by copying them; and since what we *actually* need seems to be just asm/ 
headers, this can be accomplished simply by having a kernel tree with the asm 
symlink going to asm-<target arch>(that is much more available than the 
target machine itself, right?). So, specifying an include path for those 
files could be just fine, couldn't it? However, if we use your separate rule 
idea, within that we could use either just the headers or the host machine; 
so some problems go away(i.e. the kernel tree must match the target machine's 
one for the interested decls).

Note: mk_sc includes <signal.h>, which could be a problem. But it seems also 
that we can get away by just including asm/sigcontext.h.

Bye
-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729
EOSIGN



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&opÌk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] UML on Alpha

[BlaisorBlade]

Alle 05:29, lunedì 22 dicembre 2003, Matt Zimmerman ha scritto:
> On Mon, Dec 22, 2003 at 12:15:23PM +0800, Cameron Patrick wrote:
> > I've been working on 2.4 so far.  I'm not running 2.6 on any machine at
> > all ATM, and from the sounds of this mailing list, you can't run a 2.6
> > UML on a 2.4 host?
You can. BUT if you apply the Ingo Molnar patches, THEN you can't. Both his 
combo or his host-skas patch create this incompatibility, only for skas mode.
-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Linux Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729
EOSIGN




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&opÌk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel