Site Home Page
What it's good for
Case Studies
Kernel Capabilities
Downloading it
Running it
Compiling
Installation
Building filesystems
Troubles
User Contributions
Related Links
The ToDo list
Projects
Diary
Thanks
Contacts
Tutorials
The HOWTO (html)
The HOWTO (text)
Host file access
Device inputs
Sharing filesystems
Creating filesystems
Virtual Networking
Management Console
Kernel Debugging
gprof and gcov
Running X
Diagnosing problems
Configuration
Installing Slackware
Porting UML
IO memory emulation
How you can help
Overview
Documentation
Utilities
Kernel bugs
Kernel projects
Screenshots
A virtual network
An X session
Transcripts
A login session
A debugging session
Slackware installation
Reference
Kernel switches
Slackware README
Papers
ALS 2000 paper (html)
ALS 2000 paper (TeX)
ALS 2000 slides
LCA 2001 slides
OLS 2001 paper (html)
OLS 2001 paper (TeX)
ALS 2001 paper (html)
ALS 2001 paper (TeX)
UML security (html)
LCA 2002 (html)
Fun and Games
Kernel Hangman
Disaster of the Month

Porting UML to a new architecture

Even though UML is running on a host Linux, which insulates it from the underlying platform to a great extent, some details of the hardware still leak through and make porting UML to Linux on a new architecture more than a simple rebuild.

The major aspects of the hardware that show through are

  • register names used by ptrace
  • organization of the process address space

This page will describe how to port UML to a new architecture. It will acquire new material as we learn more about how to do it. At this point, this is based on what we learned from the ppc port, which is the only real port of UML that's been done so far. The i386 port doesn't really count since that was part of the overall development of UML rather than a separate porting effort.

Below, there are references to $(SUBARCH). This is the make variable which holds the value of the host architecture in the UML build. On Intel boxes, it's "i386" and on PowerPC boxes, it's "ppc".
Overview

UML is split between architecture-independent code and headers which are found under arch/um in
  • kernel
  • drivers
  • fs
  • ptproxy
  • include
and the architecture-dependent code and definitions under arch/um in
  • Makefile-*
  • sys-*
  • include/sysdep-*
Each '*' is the name of an architecture, so the i386-specific code is under arch/um/sys-i386 and the ppc-specific code is under arch/um/sys-ppc.

The host
Not all architectures can currently run UML. The potential problem is the ability of ptrace to change system call numbers. i386 couldn't until I got the change into 2.3.22 and 2.2.15, ppc could, and IA64 and mips can't. I don't know about the other arches.

This is necessary because it's critical to UML's ability to virtualize system calls. Process system calls must be nullified in the host, and this is done by converting them into getpid.

So, before starting to work on your new port of UML, make sure ptrace is fully functional. This little program starts a child, which makes calls to getpid and prints them out, while the parent is converting the getpid calls to getppid. The parent prints out its own pid, while the child prints out what it thinks is its own pid, and they should be the same. So, if your machine is able to run UML, you will see output like this:

                
Parent pid = 3246
getpid() returned 3246
getpid() returned 3246

              
If not, you will likely get errors from ptrace. Less likely is different pids being printed out from the two processes. If either happens, then you need to figure out how to remove that restriction from the host Linux.

Note that when you compile ptrace.c, you will need to change the references to ORIG_EAX, which contains the system call number, to whatever is appropriate for your architecture.

Address space layout
Before delving into the code, you need to do some high-level conceptual thinking about how to organize the address space of a UML process. UML maps its executable, physical memory, and kernel virtual memory into the address space of each of its processes. You need to decide where to put each of these so as to minimize the likelihood of a process trying to allocate that memory for its own use.

The only arch hook at this point is where in the address space the UML binary is going to load. The other addresses are still hard-coded because they happen to work for both i386 and ppc. UML puts its own memory in the area starting at 0x5000000 and process stacks 4M below its own process stack. These choices may not work on all architectures, so feel free to generalize them. To locate a likely area on your arch, staring at /proc/<pid>/maps of various processes on the host has been the technique so far.

Architecture Makefile
You need to create arch/um/Makefile-$(SUBARCH), which contains the following definitions:
  • START_ADDR - The address where the UML executable will load in memory. This address must be chosen so that it won't conflict with any memory that a UML process is going to want to use. The i386 definition is
                        START_ADDR = 0x10000000
                      
  • ARCH_CFLAGS - Anything that needs to be added to CFLAGS goes here. Both the i386 and ppc ports use this to turn off definitions that would pull hardware-specific code into the kernel. The ppc definition is
                        ARCH_CFLAGS = -U__powerpc__ -D__UM_PPC__
                      
  • ELF_SUBARCH - This is the name of the ELF object format for the architecture. On i386, it's 'i386', but on ppc, it's not 'ppc' (it's 'powerpc'). The i386 definition is
                        ELF_SUBARCH = $(SUBARCH)
                      
Architecture headers
There are three headers, which go in arch/um/include/sysdep-$(SUBARCH), which need to be written, and each needs to contain a certain set of definitions.

ptrace.h

ptrace.h contains a number of definitions which insulate generic UML code, and its calls to ptrace, from details of the machine's register set.

First, the register set needs to be defined as struct sys_pt_regs. This is a structure which contains the machine's register set as defined by ptrace. This may be different from the machine's register set - i386 adds ORIG_EAX, which doesn't correspond to a register on the chip. The generic code won't look inside the structure directly, but will do structure copies and access it through the macros described below. The i386 definition is

                
#define UM_MAX_REG (17)

struct sys_pt_regs {
  unsigned long regs[UM_MAX_REG];
};

              
Along with this, you need a definition of EMPTY_REGS, which is a default initialization of a struct sys_pt_regs:
                
#define EMPTY_REGS { { [ 0 ... UM_MAX_REG - 1 ] = 0 } }

              

Then, you need a number of macros to allow the generic code to access information in a register set. These come in two varieties, UM_* and UM_*_OFFSET. The UM_* macros return a field from a struct sys_pt_regs which can be assigned to or its value taken, while the UM_*_OFFSET macros return a number suitable for a call to ptrace(PTRACE_SETREG, ...). Below are the required macros and their i386 definitions.

  • UM_IP(regs) - the instruction pointer from regs
  • UM_IP_OFFSET - the instruction pointer offset
                        
    #define UM_REG(r, n) ((r)->regs[n])
    #define UM_IP(r) UM_REG(r, EIP)
    #define UM_IP_OFFSET (EIP * sizeof(long))
    
                      
  • UM_SP(regs) - the stack pointer from regs
  • UM_SP_OFFSET - the stack pointer offset
                        
    #define UM_SP(r) UM_REG(r, UESP)
    #define UM_SP_OFFSET (UESP * sizeof(long))
    
                      
  • UM_ELF_ZERO(regs)
  • UM_ELF_ZERO_OFFSET - the register and offset that needs to be zeroed before branching to the entry point of a new process. This is a bit of a kludge and may be replaced with a more general UM_ELF_INIT(regs) macro.
                        
    #define UM_ELF_ZERO(r) UM_REG(r, EDX)
    #define UM_ELF_ZERO_OFFSET (EDX * sizeof(long))
    
                      
  • UM_FIX_EXEC_STACK - A hook which is called after loading an ELF image into memory. On i386, this is empty, but on ppc, for example, the stack needs to be moved to sit on a 16 byte boundary.
                        
    extern void shove_aux_table(unsigned long sp);
    #define UM_FIX_EXEC_STACK(sp) shove_aux_table(sp);
    
                      
  • UM_SYSCALL_RET(regs)
  • UM_SYSCALL_RET_OFFSET - the register and offset that contains the system call return value as it finishes.
                        
    #define UM_SYSCALL_RET(r) UM_REG(r, EAX)
    #define UM_SYSCALL_RET_OFFSET (EAX * sizeof(long))
    
                      
  • UM_SYSCALL_NR(regs)
  • UM_SYSCALL_NR_OFFSET - the register and offset that contains the system call number at the start of system call execution.
                        
    #define UM_SYSCALL_NR(r) UM_REG(r, ORIG_EAX)
    #define UM_SYSCALL_NR_OFFSET (ORIG_EAX * sizeof(long))
    
                      
  • UM_SET_SYSCALL_RETURN - stores the result of a system call in the right place in the register set. On some architectures special handling is needed, eg setting a flag on error returns on ppc.
                        
    #define UM_SET_SYSCALL_RETURN(_regs, result)	        \
    do {                                                    \
            if (result < 0) {				\
    		(_regs)->regs[PT_CCR] |= 0x10000000;	\
    		UM_SYSCALL_RET((_regs)) = -result;	\
            } else {					\
    		UM_SYSCALL_RET((_regs)) = result;	\
            }                                               \
    } while(0)
    
                      
  • UM_SYSCALL_ARG1(regs)
  • UM_SYSCALL_ARG1_OFFSET
  • UM_SYSCALL_ARG2(regs)
  • UM_SYSCALL_ARG2_OFFSET
  • UM_SYSCALL_ARG3(regs)
  • UM_SYSCALL_ARG3_OFFSET
  • UM_SYSCALL_ARG4(regs)
  • UM_SYSCALL_ARG4_OFFSET
  • UM_SYSCALL_ARG5(regs)
  • UM_SYSCALL_ARG5_OFFSET
  • UM_SYSCALL_ARG6(regs)
  • UM_SYSCALL_ARG6_OFFSET - the appropriate system call argument or offset
                        
    #define UM_SYSCALL_ARG1(r) UM_REG(r, EBX)
    #define UM_SYSCALL_ARG2(r) UM_REG(r, ECX)
    #define UM_SYSCALL_ARG3(r) UM_REG(r, EDX)
    #define UM_SYSCALL_ARG4(r) UM_REG(r, ESI)
    #define UM_SYSCALL_ARG5(r) UM_REG(r, EDI)
    #define UM_SYSCALL_ARG6(r) UM_REG(r, EBP)
    
    #define UM_SYSCALL_ARG1_OFFSET (EBX * sizeof(long))
    #define UM_SYSCALL_ARG2_OFFSET (ECX * sizeof(long))
    #define UM_SYSCALL_ARG3_OFFSET (EDX * sizeof(long))
    #define UM_SYSCALL_ARG4_OFFSET (ESI * sizeof(long))
    #define UM_SYSCALL_ARG5_OFFSET (EDI * sizeof(long))
    #define UM_SYSCALL_ARG6_OFFSET (EBP * sizeof(long))
    
                      

syscalls.h

syscalls.h needs to define a number of things related to system calls.

  • syscall_handler_t - a typedef describing the interface to the system call functions. The i386 port declares a syscall_handler_t as taking a struct sys_pt_regs as its only argument
                        
    typedef long syscall_handler_t(struct sys_pt_regs regs);
    
                      
    and the ppc port declares it as taking six unsigned longs
                        
    typedef long syscall_handler_t(unsigned long arg1, unsigned long arg2,
    			       unsigned long arg3, unsigned long arg4,
    			       unsigned long arg5, unsigned long arg6);
    
                      
  • EXECUTE_SYSCALL - a macro which takes a system call number and a register set and invokes the system call. This should match the declaration of syscall_handler_t, so the i386 port sticks the entire register set on the stack
                        
    #define EXECUTE_SYSCALL(syscall, regs) (*sys_call_table[syscall])(regs)
    
                      
    while the ppc port extracts the individual arguments
                        
    #define EXECUTE_SYSCALL(syscall, regs) \
            (*sys_call_table[syscall])(UM_SYSCALL_ARG1(&regs), \
    			           UM_SYSCALL_ARG2(&regs), \
    				   UM_SYSCALL_ARG3(&regs), \
    				   UM_SYSCALL_ARG4(&regs), \
    				   UM_SYSCALL_ARG5(&regs), \
    				   UM_SYSCALL_ARG6(&regs))
    
                      
  • ARCH_SYSCALLS - a fragment of an array initialization. This will be incorporated into the system call vector, which has the entry point for each system call in the appropriate slot. This defines system calls which are present on Linux for this architecture, but not for all of the others. An empty value is OK, and the ppc port used to define this as such. When it is not empty, it should be written with a trailing comma. Here is a piece of the i386 definition:
                        
    #define ARCH_SYSCALLS \
            [ __NR_vm86old ] = sys_ni_syscall, \
            [ __NR_modify_ldt ] = sys_modify_ldt, \
            [ __NR_lchown32 ] = sys_lchown, \
            [ __NR_madvise ] = sys_madvise,
    
                      
  • LAST_SYSCALL - this is the number of the last defined system call for this architecture, which may be one of the generic system calls, so check the numbers. It is used to pad out the otherwise undefined end part of the system call vector.
                        
    #define LAST_SYSCALL __NR_madvise
    
                      

sigcontext.h

sigcontext.h defines a few sigcontext access macros.

  • UM_ALLOCATE_SC(name) - Declares a sigcontext struct and any other data which is part of a sigcontext. It's put at the end of the locals where it's used, so it may also initialize things. The ppc definition declares a separate register set and assigns a sigcontext field to point to it:
                        
    #define UM_ALLOCATE_SC(name) \
    	struct sys_pt_regs name##_regs; \
    	struct sigcontext name; \
    	name.regs = &name##_regs
    
                      
    This will be filled in by fill_in_sigcontext, which has to match whatever is set up here.
  • SC_FAULT_ADDR(sc) - Extracts the page fault address from the sigcontext
                        
    #define SC_FAULT_ADDR(sc) ((sc)->cr2)
    
                      
  • SC_FAULT_WRITE(sc) - Zero if the fault was a read, non-zero if it was a write
                        
    #define SC_FAULT_WRITE(sc) (((sc)->err) & 2)
    
                      
  • SC_IP(sc) - Extracts the faulting ip from the sigcontext
                        
    #define SC_IP(sc) ((sc)->eip)
    
                      
  • SC_SP(sc) - Extracts the stack pointer from the sigcontext
                        
    #define SC_SP(sc) ((sc)->esp_at_signal)
    
                      
  • SEGV_IS_FIXABLE(sc) - Returns non-zero or zero, depending on whether a particular seg fault was caused by a page or protection fault, which can be fixed, or some other fault, and can't. In the latter case, the UML process will be segfaulted.
                        
    #define SEGV_IS_FIXABLE(sc) (((sc)->trapno == 14) || ((sc)->trapno == 13))
    
                      
Port implementation
The actual implementation of the port is contained in sys-$(SUBARCH). You have complete freedom in this directory, except that when it is built, it must produce an object file named sys.o which contains all the code required by the generic kernel.

Here is a list of the files used by the existing ports, along with what they define.

ptrace.c

                
int putreg(struct task_struct *child, unsigned long regno, unsigned long value)

              
This does any needed validity checking on the register and the value, and assigns the value to the appropriate register in child->thread.process_regs. If it fails, it returns -EIO.

This may be changed in the future so that it is provided with just the register set rather than the whole task structure.

                
unsigned long getreg(struct task_struct *child, unsigned long regno)

              
getreg fetches the value of the requested register from child->thread.process_regs, doing any required masking of registers which don't use all their bits. This may also be changed to take the register set rather than the task structure.

ptrace_user.c

Linux doesn't implement PTRACE_SETREGS and PTRACE_GETREGS on all architectures. This file contains definitions of ptrace_getregs and ptrace_setregs to hide this difference from the generic code. Architectures which define PTRACE_SETREGS and PTRACE_GETREGS will implement these functions as follows

                
int ptrace_getregs(long pid, struct sys_pt_regs *regs_out)
{
	return(ptrace(PTRACE_GETREGS, pid, 0, regs_out));
}

int ptrace_setregs(long pid, struct sys_pt_regs *regs)
{
	return(ptrace(PTRACE_SETREGS, pid, 0, regs));
}

              
Architectures which don't will implement them as loops which call ptrace(PTRACE_GETREG, ...) or ptrace(PTRACE_SETREG, ...) for each register.

semaphore.c

This implements the architecture's semaphore primitives. It is highly recommended to steal this from the underlying architecture by having the Makefile make a link from arch/$(SUBARCH)/kernel/semaphore.c to arch/um/sys-$(SUBARCH)/semaphore.c.

checksum.c or checksum.S

This implements the architecture's ip checksumming. This is stolen from the underlying architecture in the same manner as semaphore.c.

sigcontext.c

This defines fill_in_sigcontext, which copies data from a struct_pt_regs into a struct sigcontext. The sigcontext will be whatever was declared by UM_ALLOCATE_SC.

Other files

If Linux on your architecture defines any private system calls, you will need to implement them here. Normally, you can take the code from the underlying architecture, and you might get away with linking to the files in the other architecture that implement them.

include/asm-um/*.h
After implementing the stuff described above, you will build your shiny new UML, and the make will blow up horribly. The reason is that almost all of the headers in include/asm-um simply include their counterparts from include/asm-$(SUBARCH), like this:
                
#ifndef __UM_POLL_H
#define __UM_POLL_H

#include "asm/arch/poll.h"

#endif

              
Some of these headers will define things in ways that are incompatible with their use in UML and some will need different definitions on different architectures.

This has been handled in two ways. Where there are definitions that differ from architecture to architecture or where simple modifications need to be made to a header, those arch-dependent definitions are put in include/asm/archparam-$(SUBARCH).h, which is linked to by include/asm/archparam.h. archparam.h, in turn, is included by the headers which need those changes. At this point, they are

  • elf.h - has a number of differences between i386 and ppc
  • delay.h - i386 and ppc declare a delay value differently
  • hw_irq.h - ppc defines hard_irq_{enter,exit}, but not irq_{enter,exit}, so ppc defines irq_{enter,exit} as hard_irq_{enter,exit}
  • string.h - ppc blows up unless __HAVE_ARCH_STRRCHR is defined, which is done here
When archparam.h isn't sufficient, then the header is replaced by a symlink which points to an architecture-specific header. This header includes the generic UML header, but is able to put whatever it wants around that include, which enables it to do things like hide definitions and wrap ifdefs around the header. This has been done to system.h, processor.h, and sigcontext.h.

As an example, on ppc, include/asm-um/processor.h is now a symbolic link to include/asm-um/processor-ppc.h. processor-ppc.h wraps an ifdef around the UML generic processor.h and turns on a cpp symbol:

                
#ifndef __UM_PROCESSOR_PPC_H
#define __UM_PROCESSOR_PPC_H

#if defined(__ASSEMBLY__)
#define CONFIG_ALL_PPC

#include "asm/processor-generic.h"

#endif

#endif

              
Debugging the new port
There's no algorithm for doing this stage of the port, so I'll just describe a number of useful tricks.

gdb is available. Use it. It's usable for any part of the kernel after the beginning of start_kernel. If you need to debug anything before that, the 'debugtrace' option is handle. It causes the tracing thread to stop and wait to be attached with gdb. Then you can step through the very early boot before start_kernel.

If you're post-mortem-ing a bug and you want to see what just happened inside UML, there are some arrays which store some useful recent history:

  • signal_record - stores the last 1024 signals seen by the tracing thread, including the host pid of the process getting the signal, the time, and the IP at which the signal happened. This is a circular buffer and the latest entry is at index signal_index - 1.
  • syscall_record - the same, except it stores process system calls. It stores the system call number, the return value (and 0xdeadbeef is stored there if it hasn't returned), the UML pid of the process, and the time. It is indexed by syscall_index, so the most recent entry is at index syscall_index - 1.
These provide a decent picture of what UML has been doing lately. Looking for unusual things here immediately before a bug happened is a useful debugging technique. Correlating timestamps between the two arrays is also sometimes useful.

If you have reproducable memory corruption, an extremely useful way to track it down is to set the page that it happens on read-only and to see what seg faults when it tries writing to that page. Obviously, this only works if there aren't legitimate writes happening to that page at the same time.

Hosted at SourceForge Logo