<-- Click to support a LinuxWorld sponsor
Linuxworld
Search Linuxworld
HOME >
[More Stories]

In Admin:

Open-source vs. Microsoft tools for business-app implementation, Part 2

Readers react to phpBB & spyce series

In Programming:

Variety is the spyce of Python

How to add spyce to your life

In Desktop:

'Tis the season to frag with Linux

3 reasons for Linux newbie culture shock

In Core Linux:

Linus Torvalds answers 10 goofy questions

Knoppix makes a great GUI installer for Debian

About us

Help & feedback

Privacy

Terms of use

Advertise

IDG Worldwide


Linux for S/390, Part 2: Building the iron penguin
Linux takes to big iron within virtual machines
Jun 15, 2000
Summary
In the second article of this three-part series on the Linux port to IBM's System/390, Neale Ferguson describes how the idea of the Linux port to the S/390 came about and the technical details involved. (5,000 words)


By Neale Ferguson
Advertisement
In my first installment on Linux for S/390, I introduced the S/390 architecture and described the development of the VM/ESA operating system. With this as background, I'll now describe how the idea to port Linux to the S/390 came about and the technical details regarding the port.

  Linux on S/390: Read the whole series!

 

Two ports in a storm
As Linux grew in popularity, the general population of computer programmers and administrators became Linux literate. This was also true in the S/390 world. There was even envy within the VM community; Linux was developing in the way VM's proponents had hoped their operating system would grow before IBM's Object Code Only (OCO) and Object Code Maintained (OCM) policies, both described in the first part of this series, crippled the community's ability to contribute. The skill base, the technology, and the application base within the Linux world are all highly attractive to any organization that wishes to keep growing.

As a long-time VMer, I could see that there were great synergies between the two operating systems. The initials VM refer to virtual machines running their own operating systems as guests. Sometimes ill-behaved guests are referred to as parasites, but Linux could be a very welcome guest, especially with source code available.

Therefore, it wasn't surprising when efforts to port Linux to yet another architecture were undertaken. There were two of these efforts: one done totally in the public eye, the other (by necessity, for the developers didn't want to scare the rest of their organization) done as a skunk-work project within IBM.

i370-ibm-linux
My first attempt to do a Linux on S/390 port was back in 1997, but I had neither the time nor the gcc-compiler skills to get very far. Fortunately, Linas Vesptas and David Pitts did (and still do!) have such skills (and more) and were able to build the infrastructure that enabled a port to happen.

I joined Linas in early 1999, bringing my access to significant S/390 resources (two-way SMPs, 725 MB memory, gigabytes of disk) to help the effort. We were soon joined by several others, including Rob Van Der Heij from the Netherlands and Peter Schulte-Stracke of Germany.

With Linas as our guiding light and designer of key architectural constructs, we were able to get together a kernel, nicknamed Bigfoot and based on the 2.2.10 level, that did the basics:

  • Memory management
  • Process control
  • Primary I/O functions (device detection and limited driving)
  • Rudimentary bottom-half handling
  • RAM-disk handling

By September 1999, we were booting the kernel and had it to the stage of invoking the first user process.

Development was done primarily under VM/ESA and Hercules. The trace facilities of VM were indispensable. VM has many sophisticated trace capabilities that allow you to shoot bugs with I/O, virtual memory activities, program flow and control, register and storage modification, etc. It can produce bug reports interactively or generate a printout. Most of the time we would do things interactively, but the print facility, when coupled with the system map and a couple of simple scripts, produced extremely useful debugging aids.

It had been a long time since I as excited about programming as I was when I worked with Linas' early code. I used VM to trace the kernel and could see it had problems, so I downloaded the code, built a cross-compile environment, and started to hack away. What a great time I had, applying fixes and getting them running! Soon I was getting into the guts of the kernel and creating the code that brought S/390 and Linux together. Dynamic address translation and I/O support were just plain fun to implement.

Bigfoot was a totally public effort. Communications and diffs of the source code were published on Websites and on the LINUX-390 mailing list.

Amid our gradual progress, we began to hear rumors of a skunk-work project within IBM that was also porting Linux to S/390.

s390-ibm-linux
IBM is an interesting organization. It has more than its fair share of Nobel Prize winners, has some of the best minds in the industry, and a more than generous quota of people who are open and always willing to help. However, because of its size, it also has a bureaucracy of immense proportions and a goodly number of empire builders and ultraconservatives. This should not be a surprise as any organization this large is, in fact, a microcosm of society.

Thus, a project as politically sensitive and, perhaps, as radical as this had to proceed carefully -- it must have scared the living daylights out of some within the company. Therefore, a project involving a small group of dedicated developers was created and funded to develop the port.

The downside of this secrecy was that neither the lessons learned nor the information and code developed were able to be exchanged with the folks doing the other port. Numerous lessons learned during the development of the Bigfoot port were relearned in the IBM effort. This is a classic example of why true open source development can be so valuable.

There has been some justified feeling among the Bigfoot developers that their efforts were undervalued. If nothing else, however, I believe the public and published progress of the Bigfoot port helped force IBM's hand so that, on December 18, 1999, the company published the diffs to all its key components. The IBM team is now in constant public communication with the community through LINUX-390.

IBM is still getting the feel of how things are done in the open source world. In my personal opinion, it seems that Big Blue's management retains a sense of the "not invented here" syndrome. So far, the interaction between the community and the developers has been positive. Hopefully, these positives will promote the cause of open source and lead to a first-class port of Linux to S/390.

Getting it yourself
Interested? Why not check out the port yourself, even if it's only to see how things are implemented in a different environment? You can obtain a copy from the Marist College Linux for S/390 site (see the Resources section below the URL). Here, you'll get the instructions, the kernel, and a couple of filesystems.

Once you download all this, take some time to look at the code unique to the S/390 port. The next sections of this article will help you understand the technical ins and outs of the S/390 implementation.

New configuration Questions
The first step to configuring Linux on the S/390 happens with the Linux kernel configuration. Update your makefile with ARCH:=s390 and begin the configuration with make config or make menuconfig and look for the parameter prompts in Table 1

Table 1. Linux on S/390 build parameters
ParameterDescription
CONFIG_ARCH_S390Select this option if you want to run the kernel on one of IBM's mainframes of the S/390 generation. You should have previously installed the s390-compiler released by IBM (based on gcc-2.95.1).
CONFIG_IPLABLEIf you want to use the produced kernel to boot (or initial program load (IPL), as it's often called in S/390) directly from a device, you have to merge a boot sector specific to the device into the first bytes of the kernel. You will have to select the boot device on another question that pops up when you select CONFIG_IPLABLE.
CONFIG_IPL_TAPESelect this option if you want to boot the image from a tape.
CONFIG_IPL_RDR_VMSelect this option if you are running under VM/ESA and want to boot the image from the emulated card reader.
CONFIG_IPL_RDRSelect this option if you want to IPL the image from a real card reader. Maybe you still have one and want to try it. Not tested.
CONFIG_DASDEnable this option if you want to access disks directly utilizing S/390's channel subsystem commands. This is necessary for running natively on a single image or an LPAR.
CONFIG_DASD_FAST_IOSelecting this option enables fast I/O for disks. That means that, if an I/O request is pending, the next I/O command is already issued at interrupt time. This option significantly speeds up I/O because S/390 doesn't schedule the bottom halves as often as Intel.
CONFIG_S390_PARTITIONEnable this option to assure standard IBM labels on the disks. You must enable it if you are planning to access disks also attached to another IBM mainframe operating system (OS/390, VM/ESA, VSE/ESA).
CONFIG_DASD_ECKDECKD devices are the devices most commonly used. You should enable this option unless you are certain that you have no ECKD devices.
CONFIG_DASD_CKDCKD devices are currently unsupported.
CONFIG_DASD_FBAFBA devices are currently unsupported.
CONFIG_IEEEFPU_EMULATIONInclude IEEE floating point emulation code.
CONFIG_MDISKThis option is used under VM only. With this flag enabled (Y), your S/390 can use a reserved minidisk under VM. The minidisk must be formatted and reserved under VM/CMS.
CONFIG_MDISK_SYNCThis option is used under VM only. You can make the minidisk operation synchronous.
CONFIG_CTCThis option gives you the ability to make TCP/IP connections via virtual, parallel, or ESCON channels between Linux for S/390 machines and between Linux for S/390 and OS/390, VM, and/or VSE machines.
CONFIG_IUCVThis is a VM-only network device driver that provides for very fast communication between VM userids.
CONFIG_3215The 3215 console driver is used to read and write to a 3215 line-mode console (a type of TTY).
CONFIG_3215_CONSOLEThis option enables console output on the first 3215 console in the system. It prints kernel errors and kernel warnings to the 3215 terminal, in addition to the normal output on the TTY device.
CONFIG_HWCThe hardware console (HWC) is an alternative terminal, usually required for a native Linux for S/390 installation, although it is also run under VM.
CONFIG_HWC_CONSOLEThis option enables console output on the first hardware console in the system. It prints kernel errors and kernel warnings to the hardware console in addition to the normal output on the TTY device.

So, let's look at those aspects within the S/390 architecture that these configuration questions influence.

S/390 architectural considerations
S/390 is a big-endian architecture that has:

  • Sixteen 32-bit general-purpose registers
  • Four floating-point registers in the older systems and sixteen in the newer ones, according to the IBM and IEEE formats
  • Sixteen 32-bit control registers that control machine operation for address spaces, interrupt masks, etc.
  • Sixteen 32-bit access registers that control the concurrent use of multiple address spaces

Program status word
The heart and soul of S/390 is the program status word (PSW). The PSW is the most important register on the machine; it is 64 bits long and serves multiple roles. The PSW has several advantages over a normal program counter in that you can change multiple settings (such as address translation and program counter) in a single instruction. The following table breaks down the PSW into its component bits:

Table 2. PSW component bits
BitValue
0Reserved. Must be 0, or a specification exception occurs.
1Program Event Recording (PER). A value of 1 indicates that PER is enabled. PER is used to facilitate debugging -- single stepping, for example.
2-4Reserved. Must be 0.
5Dynamic address translation (DAT). A value of 1 means that DAT is on.
6

Input/output interrupt mask.
7External interrupt mask. Used primarily for interprocessor signaling and clock interrupts.
8-12PSW key. Used for a complex-memory protection mechanism not used under Linux.
13Machine check mask. A value of one means that machine check interrupts are enabled.
14Wait state. Set this to 1 to stop the processor except for interrupts and give time to other LPARs.
15Problem state. If set to 1, certain instructions are disabled. All Linux user programs run with this bit enabled.
16-17Address space control. The potential meanings for values in these bits are as follows:

  • 00 -- Primary space mode, with DAT on. The Linux kernel currently runs in this mode; control register 1 (CR1) is affiliated with this mode and points to the primary segment table origin, etc.
  • 01 -- Access register mode. This mode is used in functions to copy data between kernel and user space.
  • 10 -- Secondary space mode, not normally used Linux except to copy data between the kernel and user spaces. Control register 7 (CR7) is affiliated with this mode. Normally CR13 is mapped to CR7, allowing the copying of data between the kernel and user space. We do this as follows: we set AR2 to 0 to designate that its affiliated GPR (GPR2) should point to primary (kernel space). We set AR4 to 1 to designate that affiliated GPR (GPR4) should point to secondary (home or user space) and then essentially do a memcopy(gpr2,gpr4,size) to copy data between the address spaces. The reason we use home for the kernel and don't keep the secondary space free is that the code will not normally run in secondary space.
  • 11 -- Home space mode. All user programs run in this mode. It is affiliated with CR13.

18-19Condition codes (CC).
20Fixed point overflow mask. This bit is normally set to 0; if it is sent to 1, floating point unit (FPU) exceptions for this event occur.
21Decimal overflow mask. This bit is normally set to 0; if it is sent to 1, floating point unit (FPU) exceptions for this event occur.
22Exponent underflow mask. This bit is normally set to 0; if it is sent to 1, floating point unit (FPU) exceptions for this event occur.
23Significance mask. This bit is normally set to 0; if it is sent to 1, floating point unit (FPU) exceptions for this event occur.
24-31Reserved. Must be 0.
32If this bit is set to 1, 31-bit addressing mode should be used; if it is set to 0, 24-bit addressing mode should be used for backward compatibility. Linux always runs with this bit set to 1.
33-64Instruction address (program counter).

Interrupts are implemented by storing the current PSW and loading a new PSW. This is similar in concept to a vector interrupt table. There are five main types of interrupts defined for S/390. Each type has several different classes that qualify the type of interrupt and are stored in a specified low-core area upon interrupt. These types are:

  1. External: External events such as timers or signals from other CPUs. The event type is stored as the qualifier.
  2. Supervisor call: Program-controlled signal to operating system. A code 0x00-0xff is stored as the qualifier.
  3. Program check: Invalid instructions, page translation exceptions, access violations. The type of program fault is stored as the qualifier.
  4. Machine check: Hardware component warning or failure notification. The type of failure is stored as the qualifier.
  5. I/O: Input/output device status changes. The identifier of the device causing the interrupt is stored as the qualifier.

On VM, you can display these PSWs for a virtual machine or you can use the hardware-management console if running on the bare iron or within an LPAR:


Figure 1. PSW display

Prefix page
This per-CPU memory area is too intimately tied to the processor not to mention. It exists between the real addresses 0 and 4096 (the first page) on the processor and is exchanged with a page in absolute storage by the set prefix instruction in Linux's startup. There is an instance of this page for each real or virtual processor attached to the virtual machine. The prefix register holds the address of the prefix page. Bytes 0 through 512 (200 hex) are used by the processor itself for holding such information as exception indications and entry points for exceptions.

Linux uses bytes after 0xc00 hex for per-processor globals. The closest thing to this on traditional architectures is the interrupt vector table. This simplifies some of the kernel coding. However, it means that we now cannot catch stray null pointers in the kernel without hardcoded checks. You can find more information in Barrow, 2000 in the Linux source tree -- see Resources for the path.

Addressing
First, some quick definitions from the ESA/390 Principles of Operations (ESAPOP) document by IBM:

For purposes of addressing main storage, three basic types of addresses are recognized: absolute, real, and virtual. The addresses are distinguished on the basis of the transformations that are applied to the address during a storage access. Address translation converts virtual to real, and prefixing converts real to absolute. In addition to the three basic address types, additional types are defined which are treated as one or another of the three basic types, depending on the instruction and the current mode.

  • An absolute address is the address assigned to a main storage location. An absolute address is used for a storage access without any transformations performed on it.
  • A real address identifies a location in real storage. When a real address is used for an access to main storage, it is converted, by means of prefixing, to an absolute address.
  • A virtual address identifies a location in virtual storage. When a virtual address is used for an access to main storage, it is translated by means of dynamic address translation to a real address, which is then further converted by prefixing to an absolute address.
  • A primary virtual address is a virtual address that is to be translated by means of the primary segment-table designation. Logical addresses are treated as primary virtual addresses when in the primary-space mode. Instruction addresses are treated as primary virtual addresses when in the primary-space mode, secondary-space mode, or access-register mode.
  • A secondary virtual address is a virtual address that is to be translated by means of the secondary segment-table designation. Logical addresses are treated as secondary virtual addresses when in the secondary-space mode.
  • An AR (access register) specified virtual address is a virtual address that is to be translated by means of an AR-specified segment-table designation. Logical addresses are treated as AR-specified addresses when in the access-register mode. Access registers allow you to use 16 2 GB address spaces concurrently.
  • A home virtual address is a virtual address that is to be translated by means of the home segment-table designation. Logical addresses and instruction addresses are treated as home virtual addresses when in the home space mode.

Dynamic address translation
The process of translating a virtual address to a real address consists of a lookup using two tables: a segment table and a page table. These tables reside in real or absolute storage.


Figure 2. Dynamic address translation

Figure 2 presents a simplified overview of dynamic address translation as it's performed in S/390. Basically:

  • A 31-bit virtual address is broken down into a segment index (SX), page index (PX), and byte index (BX).
  • Depending on the addressing mode, a control register points to a segment table origin.
  • Each 32-bit entry within the segment table represents 1 MB of storage and indicates whether there is a valid page table available to map real storage.
  • The SX portion of the virtual address is used to index into the segment table.
  • The indexed entry points to a page table.
  • Each entry within the page table represents 4,096 bytes of storage and indicates whether the page actually exists in real storage.
  • The PX portion of the virtual address is used to index into the page table.
  • The indexed entry points to the beginning of a page in storage (a page frame address).
  • The BX portion of the virtual address is used as the offset within this page frame. The result is the real address.

There is one more step that S/390 uses: transforming the real address into an absolute address by adding the contents of the prefix register. This mechanism allows the implementation of SMP in the architecture by providing each processor with its own page 0.

There is also a hardware shortcut available called the translate lookaside buffer (TLB). A lookup of this table uses the SX and PX indexes to index a table of recently accessed page frames. This search occurs in parallel with the normal translation process. If an address is found in the TLB, then the normal process is terminated and the page frame address found in the TLB is used to form the real address.

I/O layer
In contrast to most other hardware architectures, ESA/390 has defined a unified I/O access method. This relieves the device drivers of some responsibilities, as they don't have to deal with differing bus types, polling versus interrupt processing, shared versus nonshared interrupt processing, DMA versus port I/O (PIO), and other hardware features as much as they would on other systems. However, this implies either that every single device driver needs to implement the hardware I/O attachment functionality itself or that the operating system must provide for a unified method to access the hardware, thus providing all the functionality that every single device driver would otherwise have to provide. In order to build common device support for ESA/390 I/O interfaces, a functional layer was introduced that provides generic I/O access methods to the hardware.

The ESA/390 hardware platform knows about a huge variety of peripheral attachments, like disk devices (also known as DASD), tapes, and communication controllers. All these devices can be accessed by a well-defined access method and the present I/O completion in a unified way: I/O interruptions. Every single device is uniquely identified to the system by a so-called subchannel, where the ESA/390 architecture allows for 65,536 devices to be attached. (See the reference to Lung in Resources.)

In order not to introduce a new I/O concept to the common Linux code, Linux for S/390 preserves the IRQ concept and semantically maps the ESA/390 subchannels to Linux as IRQs. This allows Linux for S/390 to support up to 65,536 different IRQs, representing a single device each.

There are several new devices defined for S/390:

  • /dev/dasdxn -- Disks that use the extended count key data (ECKD) geometry, such as 3390. Under VM, these can be subsets of a full device that Linux sees as a real (although smaller than normal) device. These minidisks can live anywhere on a real disk and can be moved from real device to real device.
  • /dev/mndx -- VM minidisks of any geometry. The minidisks may be ECKD, count key data (CKD), or fixed-block architecture (FBA) geometries. They appear to Linux as pure fixed-block devices. As with other VM minidisks, these can live anywhere and can, in fact, be VM RAM disks.
  • /dev/ctcn -- Channel-to-channel adapter, which is a device used to connect CPUs. Under VM, these can be virtual (memory-to-memory constructs) and can be used to connect virtual machines.
  • /dev/osan -- The open systems adapter, which will eventually provide a Fast Ethernet, Token Ring, FDDI, or ATM interface to a network. Currently, only Ethernet and Token Ring are supported.
  • /dev/iucv -- A VM-only method of connecting virtual machines. This is basically a storage-to-storage transfer mechanism that transfers data up to 500 MBs. (You read it right: bytes per second, not bits!)

Support for an emulated dumb TTY and the S/390 hardware console for booting Linux is provided.

Floating point
Until recently, IBM had its own floating-point hardware implementation that predated IEEE. It had advantages over IEEE, but also had disadvantages, the most obvious and important of which is compatibility! Not all of the S/390 hardware has the IEEE support, but the Linux for S/390 code incorporates software emulation (just like 80387 emulation on the Intel platform).

Control registers
Control Registers are used to modify the operation of the S/390. Linux for S/390 uses the following control register settings.

Control register 0


Figure 3. Control register 0

Some notes on Figure 3:

  1. This bit is set for VM configurations only. IUCV is used as a TCP/IP network driver.
  2. Floating-point registers 0, 2, 4, and 6, are available on all ESA/390 models. The remaining 12 floating-point registers (1, 3, 5, and 7 through 15) are referred to as the additional floating-point (AFP) registers. The AFP registers are installed in the CPU when the basic floating-point extensions facility is installed and can be used only if bit 13 of control register 0, the AFP-register control bit, is set to 1. Attempting to use an AFP register when the basic floating-point-extensions facility is not installed results in a specification exception. Attempting to use an AFP register when the basic floating-point extensions facility is installed and the AFP-register control bit is 0 results in an AFP-register data exception (DXC 1).

Control register 1
This register points to the segment table for the primary address space and defines the length of the table.


Figure 4. Control register 1

Control registers 2 through 5
These registers are used for linkage-stack and address-space operations. In Linux for S/390, these registers are saved and restored for each task but never set.

Control register 6
I/O devices can have an interrupt subclass mask associated with them. This facilitates the selective enabling or disabling of interrupts from a class of I/O devices. For example, low-speed disks could all belong to a single class.


Figure 5. Control registers 6

Control register 7
Control register 7 holds the address of the segment table for the secondary address space.


Figure 6. Control registers 7

Control register 8
This register is used for monitor calls (MC). In Linux for S/390, this register is saved and restored for each task but never set.

Control registers 9 through 11
These registers are used for program event recording (PER). In Linux for S/390, these registers are saved and restored for each task but never set.

Control register 12
This register is used for tracing. The register is saved and restored for each task but never set.

Control register 13
This register points to the home space segment table.


Figure 7. Control registers 13

Control register 14
This register is used to control some machine check conditions.


Figure 8. Control registers 14

Control register 15
This register is used for linkage-stack operations. In Linux for S/390, this register is saved and restored for each task but never set.

Address spaces
On Intel, it is quite easy to recognize a kernel address as being one greater than user space high memory (in this case 0xC0000000). Addresses lower than this are the ones in the current running program on this processor (if we're discussing an SMP box). If you're using the virtual machine (VM) as a debugger, it is quite difficult to know which user process is running, as the address space you are looking at could be from any process in the run queue. Thankfully, address spaces don't normally overlap and you can recognize the code by cross-referencing with a dump made by objdump (more about this later).


Figure 9. Intel's address spaces

The limitation of Intel's addressing technique is that the Linux kernel uses a very simple real address for the virtual addressing technique:

Real address = Virtual address - user space high memory

This means that on Intel the Linux kernel can typically only address 1 GB:

High memory = 0xFFFFFFFF - 0xC0000000 = 1 GB

1 GB is thus all the RAM that these machines can typically use. They can lower user high memory to 2 GB or less, and thus be able to use 2 GB of RAM. However, this shrinks the maximum size of user space from 3 GB to 2 GB: they have a no-win limit of 4 GB unless they go to a 64-bit architecture.

S/390's limitations and strengths make it slightly different. For backward compatibility, only 31 bits (2 GB) of our 32-bit addresses are used. However, we use entirely separate address spaces for the user and the kernel. This means we can support 2 GB of nonextended RAM, and more with the extended memory management swap device and 64-bit addressing when it comes along.


Figure 10. S/390's address spaces

Using System/390's address-space support allows operations like copying back and forth between user space and kernel space to be implemented with just a few instructions.

Using VM/ESA's virtual machines, you can facilitate horizontal growth by simply defining additional virtual machines running Linux.

Debugging under VM/ESA
In addition to such debugging facilities in Linux as gdb, objdump, and strace, there is a vast set of tools available to the kernel hacker under VM/ESA. The most useful of these is the TRACE command. With this command, VM will trap various events or instructions within a virtual machine. You are able to step through instructions and watch for changes in the contents of storage or registers, restricting your activity to one virtual CPU out of many. The following is an overview of what's available, with examples:

Example 1
Trace syscalls and show me the registers and the contents addressed by register 1 when the trap is sprung. These are implemented by the supervisor call (SVC) instruction. On interrupt, the user address space is designated as the secondary address space:


Figure 11. Tracing syscalls

Example 2
Trace all supervisor calls. Don't stop. When trap springs, issue a command to display 16 bytes of storage in the secondary address space pointed to by register 1, as well as the other general registers.

-> 40043E2E" SVC

0AAE

-> 0001909A' CC 0

In the S/390 implementation, the code X'AE' equates to the rt_sigaction system call.

The storage addressed by register 1 is displayed as well as the contents of the registers:


7FFFF450  00000001 00000000 00000000 00000000 06 L0565F450
GPR  0 =  7FFFF508  7FFFF450  00000015  7FFFF3C0            
GPR  4 =  7FFFF450  00000008  00424FC0  7FFFF8F8            
GPR  8 =  00401B9C  7FFFF600  7FFFFE88  7FFFF570            
GPR 12 =  C0114AE0  C0043D84  C0043DBC  7FFFF340            
-> 400AC174" SVC   0A39     -> 0001909A'   CC 0            
V400AC174  0A39A748 F0011524 A7B40003 07FE0D10 06 L07D96174  
GPR  0 =  7FFFF508  400AC174  00000190  00000190            
GPR  4 =  7FFFF450  00000008  00424FC0  7FFFF8F8            
GPR  8 =  0040233C  7FFFF8F8  7FFFFE88  7FFFF690            
GPR 12 =  C0114AE0  80424FC8  80425240  7FFFF690            
-> 40043FD6" SVC   0AAF     -> 0001909A'   CC 0            
V7FFFF588  00390000 00000000 00000000 00000000 06 L0565F588  
GPR  0 =  7FFFF520  7FFFF588  00000000  7FFFF588            
GPR  4 =  7FFFF608  00000008  00424FC0  7FFFF8F8            
GPR  8 =  00000000  4003847C  7FFFFE88  7FFFF520            
GPR 12 =  C0114AE0  C0043F68  C0043FA2  7FFFF498

Example 3
Trace timer pops by tracing external interruptions of type 0x1004, which signify the popping of the S/390 clock comparator:


  TRACE EXTERNAL                                          
*** 0001B2A0'   EXT     1004 -> 000198B2'          
*** 0001B2A0'   EXT     1004 -> 000198B2'          
*** 0001B2A0'   EXT     1004 -> 000198B2'          

Example 4
Trace the first X'40' bytes of instructions and any changes to the contents of registers in the I/O top-half processor.


D PSW I/O
I/O 000C  38 OLD 070C0000 800703D0   78  NEW 04080000 800197BC
TRACE I R 197BC.40 RUN
TRACE G R 197BC.40 RUN
-> 000197BC' ST    50F00C00 >> 00000C00    CC 0                    
   000197C0' TM    91010039    00000039    CC 0                    
   000197C4' BRC   A7840004 -> 000197CC'   CC 0                    
-> 000197CC' AHI   A7FAFF08    CC 2    G15=056318E8                
   000197D0' SRL   88F00003    00000003    CC 2    G15=00AC631D    
   000197D4' SLL   89F00003    00000003    CC 2    G15=056318E8    
   000197D8' STM   900EF068 >> 05631950    CC 2                    
   000197DC' ST    5020F0E8 >> 056319D0    CC 2                    
   000197E0' MVC   D203F0A40C00 >> 0563198C    00000C00    CC 2    
   000197E6' STAM  9B0FF0A8 >> 05631990    CC 2                    
   000197EA' MVC   D207F0600038 >> 05631948    00000038    CC 2    
   000197F0' XC    D706F000F000 >> 056318E8    056318E8    CC 0    
   000197F6' MVI   9238F0EF >> 056319D7    CC 0                    
   000197FA' SLR   1F00        CC 2    G00=00000000                

Example 5
Trace I/O operations to a network driver (using network devices X'440' and X'441'):


TR I/O 440 INT CCW RUN
TR I/O 441 INT CCW RUN
-> 0002059A' SSCH  B2334000    0034D344    CC 0    SCH 0001    DEV 0441
            CPA 07EFDCE0   PARM 00000000    KEY 0  FPI C0  LPM 80        
VDEV 0441 CCW E3600000 00000000 STS 0C                                  
          CCW 0160005C 05820000 STS 00 DATA 005C005A08000000 ... STS 0C  
          CCW 03200000 00000000 STS 0C                                  
*** 00078A56'   I/O DEV 0441 -> 000197BC'   SCH 0001   PARM 00000000    
*** 0001B2A0'   I/O DEV 0440 -> 000197BC'   SCH 0000   PARM 00000000    
-> 0002059A' SSCH  B2334000    0034D154    CC 0    SCH 0000    DEV 0440
            CPA 07EFDC70   PARM 00000000    KEY 0  FPI C0  LPM 80        

Summary
IBM has provided the open source community with a robust implementation of Linux that exploits the strengths of the S/390 architecture. In addition, the tools and facilities provided by VM/ESA enable a developer to perform complex and exhaustive testing in what appears to be his or her own S/390 processor.

In the final installment in this series, of articles I will be looking at Linux for the S/390 in action. I will attempt to address such questions as: What can you run on it? What does it look like? How does it behave?


About the author
Neale Ferguson is a longtime IBM S/390 system administrator with over nineteen years of experience with VM/ESA. He worked on the non-IBM port of Linux to S/390 and jumped to the IBM-sponsored effort as soon as it was released. Formerly with TAB Limited in Sydney, Australia, he currently works as a consultant at Computer Associates in Reston, Va.

Resources
  • Marist College Linux for S/390 site:
    http://linux390.marist.edu
  • ESA/390 Principle of Operations (ESAPOP) (IBM, 1997):
    http://www.s390.ibm.com/bookmgr-cgi/bookmgr.cmd/BOOKS/DZ9AR004/CCONTENTS?SHELF=DA3413A6
  • Linux/390 at Princeton University:
    http://penguinvm.princeton.edu
  • Linas Vepsta's site:
    http://linas.org/linux/i370.html
  • IBM's overview of S/390:
    http://www.s390.ibm.com/linux
  • IBM resources for Linux for S/390:
    http://www.ibm.com/s390/vm/linux
  • IBM's Open Source Zone, a site for developers:
    http://www.ibm.com/developer/opensource
  • System/390 on Intel-based servers, from Fundamental Software:
    http://www.funsoft.com
  • Linux for S/390, brought to you by Millenux GmbH i.G.:
    http://linux.s390.org
  • ">http://linuxvm.org -->
    LINUX-390 mailing list:
    mailto:listserv@vm.marist.edu
  • Information on the IBM/360, from Data General, 1997:
    http://www.meteksan.com.tr/www.dg.com/about/html/ibm_360.html
    Information can also be found in the Linux source tree. See especially: Lung, 1999:
    /linux/Documentation/s390/cds.txt
    Barrow, 2000:
    /linux/Documentation/Debugging390.txt

  • Copyright © 1998-2002 LinuxWorld.com, an IDG Communications company.


     <-- Click to support a LinuxWorld sponsor