Installing AIX on Qemu!

YES it’s real!

I’m using the Linux subystem on Windows, as it’s easier to build this Qemu tree from source. I’m using Debian, but these steps will work on other systems that use Debian as a base.

First thing first, you need to get your system with the needed pre-requisites to compile:

apt-get update;apt-get upgrade apt-get install build-essential pkg-config libz-dev libglib2.0-dev libpixman-1-dev libfdt-dev

Great with those in place, now clone Artyom Tarasenko’s source repository

git clone --branch 40p-20190406-aix-boots --single-branch https://github.com/artyom-tarasenko/qemu.git

Since the frame buffer apparently isn’t quite working just yet, I configure for something more like a text mode build.

./configure --target-list=ppc-softmmu --disable-sdl --disable-vnc --disable-gtk

Now for me, GCC 7 didn’t build the source cleanly. I had to make a change to the file config-host.mak and remove all references to -Werror. Also I removed the sound hooks, as we won’t need them. remove the following lines:

CONFIG_AUDIO_DRIVERS=oss CONFIG_AUDIO_OSS=m

Now you can build Qemu. it’ll happily build in parallel so feel free to build using the -j parameter with how many cores you have. I have 32, so I use

make -j32

Okay, all being well you now have a Qemu. Now following the steps from
Artyom Tarasenko’s blog post, we can get started on the install!

First we create a 8GB disk

qemu-img create -f qcow2 aix-hdd.qcow2 8G

Next we need the custom BIOS with serial as the console.

wget https://github.com/artyom-tarasenko/openfirmware/releases/download/40p-20190413/q40pofw-serial.rom

You’ll need some AIX. I tried a 3.2.5 CD-ROM and it didn’t pick up, but AIX 4.3.3 did.

Now with all those bits in place, it’s time to run Qemu.

./ppc-softmmu/qemu-system-ppc -M 40p -bios q40pofw-serial.rom -serial telnet::4441,server -hda aix-hdd.qcow2 -vga none -nographic -net none -cdrom Volume_1.iso

Now telnet to your localhost on port 4441 and you will see the console doing it’s BIOS initialize and eventually drop to the OK prompt.

One trick I’ve found is that from the Open Firmware prompt you can find out what partitions are recognized from the firmware. If it see’s partitions then there is some hope that the image you have is valid enough to boot. In the last few days I’ve found quite a few AIX images, which are lacking the partition table, and unable to boot.

.partitions cdrom

simply type in boot cdrom:2 to kick off the installer. It may take a minute or so for the installer to kick off.

If all goes well, you’ll see the BIOS reload itself, then after a minute you’ll be prompted to press 1 to select the console

It doesn’t echo, don’t panic!

Next select your language. I’m doing English.

Next it’ll ask about installation type. Default ought to be fine.

Because this will destroy the contents of the disk (which doesn’t matter as it’s blank) it’ll prompt for confirmation.

After this it’ll begin the installation. Depending on how fast your disk & CPU is this will take a while.


For me, the installation took about 11 minutes. This is using my Xeon E5-2667 v2. It took 17 minutes on my 2006 Mac Pro, with X5365’s it .

After it’s done, right around the 96% time it’ll reboot back to the BIOS

Once you are back at the OK prompt, you can now boot disk:

it’ll look like it’s hung for a minute, then it’ll start booting from disk!

Once the OS is booted up, you select the terminal type. I’m using putty but I’ll select the vt100. Of note the function keys are selected by hitting escape and then the number key. So F3 is ESC 3.

I’m just going to finish the install, as we can always run smitty to mess with the system more, but right now I’m just interested in a base install of the BOS (Base Operating System, and IBM ISM).

A few moments later, you’ll get dumped to the login prompt.

By default there is no password, so just login as root, and there you go, your very own virtual AIX 4.3 system.

# uname -a AIX localhost 3 4 000000004C00

So there you go! All thanks to Artyom’s hard work!

Added UDP to Qemu0.90

Yes, I know it’s kinda pointless as it’s horribly out of date, but I’m still having fun. Anyways now it’ll integrate with dynamips!

So yeah, in this example, instead of the usual “-net user” and the built in SLiRP stack, this uses UDP to talk to a stand-alone SLiRP stack. This will let you plug your Qemu into virtual Ethernet switches/hubs and interfaces of virtual routers. Even mixing and matching connections to different emulators that use UDP to exchange packets.

In this case I have a VMDK loaded with a NE2K-PCI driver, and QuakeWorld for MS-DOS. I also made the MPU401 external although it’s hanging on a secondary flag…

qemu.exe -L pc-bios -m 64 -soundhw sb16,adlib -mpu401 xx -net nic,model=ne2k_pci -net socket,udp=127.0.0.1:4000,remote=127.0.0.1:4001 -hda qworld.vmdk

This has the Qemu instance listen on UDP port 4000, and connect to the same physical host on port 4001.

The recipical for the SLiRP stack from my bashed Dynamips is:

slirp_rdr.exe 4001 127.0.0.1 4000

Which in this case listens on port 4001, and connects back on port 4000.

Hopefully it makes some sense to someone.

Download it, if you want!

Download Qemu090b

Degrading qemu performance in DooM Part II

ticks for demo (fewer is better)

VersionASM FixedDiv/FixedMulC
0.9.0259268
0.10.5299300
0.11.0316317
0.12.0289281
0.12.5290282
0.14.0282274
0.14.1280269
20180430192195
20190218187187

So after the last round, I went ahead and dug out my crap version, where I had just recently found a nice abs() fix for a FixedDiv issue that the old iD code suffers from, and re-built a version of DooM that both used the assembly fixed division, and another with the C version. To compile I used my old GCC 2.7.2.3 to build with the flags:

-m486 -msoft-float -ffast-math -O2 -fforce-addr -fomit-frame-pointer

So here we go using the versions of Qemu that I can build quickly with GCC 3.4.5 MinGW, along with the last two pre-built Win64 builds.

It’s kind of interesting just how close the performance is between the two versions.

Naturally the real test is to run it on actual hardware, and to try a few versions of Watcom C.

Maybe the real takeaway is that Qemu runs GCC built code better…?

Adding DOSBox’s MPU401 to Qemu 0.90

I thought this may be something cool, if not kind of pointless. Anyways the MPU401 UART can be run like a traditional serial port with an IRQ, in intelligent mode, or just as a ‘dumb’ device you can just bit bang to talk to MIDI devices. So while playing with DOSBox I thought it’d be fun to take it’s emulation and plug it into Qemu.

And this is the end result.

It’s far from perfect, when it works it does tend to work well, although it fails to work with things like Return to Zork, but it does work with DMX’s sound code in DooM and the MPU401 driver for Windows 3.1

While doing this I was originally struggling with mapping the IO ports. Qemu has some functions to map in the memory model to assign a function that will trap read/write space. In this case base is 0x330 the base of the MPU401 device.

register_ioport_write(base, 8, 1, mpu401_ioport_write, s); register_ioport_read(base, 8, 1, mpu401_ioport_read, s);

I was thinking that the port 0x331 needed to be mapped in the same way, but it turns out after looking through more of the source, it’s actually a word aligned access. So in that case you can use a switch to see which port is actually being accessed.

static uint32_t mpu401_ioport_read(void *opaque, uint32_t addr) { switch(addr&0xf) { case 0: return(MPU401_ReadData(addr,0)); break; case 1: return(MPU401_ReadStatus(addr,0)); break; default: return(0xff); break; } return(0xff); }

Pretty simple, right?

And from there it’s a matter of mapping the DOSBox MPU code, along with the Windows interface code. Since I’m not using intelligent or IRQ mode, I just amputated the code where applicable.

If anyone wants to look at what I did to merge into anything else (and probably do a better job!) it’s on sourceforge as mpu401.c.

Otherwise the binary is available on sourceforge:

Download Qemu090b

Degrading qemu performance in DooM

Quick table… its late.

I’m using MS-DOS 5 & this benchmark suite loaded into a VMDK, and ran a few tests to check performance numbers.

version2 3d bench3 chris bencha doom ticksc quake demo
0.9.0182257.426346.4
0.10.5204247.649141.7
0.12.5305.1296.747546.8
0.13.0305.3284.351145.7
0.14.1289.6285.350945.2
0.15.0213.4176.952015.3
1197.9152.154615.5
2.4.0.1392.1340.674324.2
3.1.50405462.3149733.3

I snagged 3.1.50 from https://qemu.weilnetz.de/w64/

better performance than v2, sure, but for interactive stuff.. not so much.

So what is really going on here? Why is 0.90 so much faster when it comes to doom, and how is it possible that it’s the slowest in raw CPU performance. And fastest at IO? It appears that the crux of the issue is simply how it handles its IO, heavily favoring device performance VS CPU.

I’ll have to follow up with more builds and reading release notes to see what changed between releases. And what was it exactly that broke between gcc 3 and 4, and why the rip had to be.

I still like 0.90, if anything for it’s ability to run NeXTSTEP and NetWare.

QEMU Advent Calendar 2018

It’s that time of the year again!

Every day there will be a ‘tiny’ OS to run on Qemu!

The QEMU Advent Calendar 2018 features a QEMU disk image each day of December until Christmas. Each day a new package becomes available for download.

Every download contains a little ‘run’ shell script that starts the QEMU emulator with the recommended parameters for the disk image. Disk images are either contained directly in the download or are downloaded by the ‘run’ script (you need to have installed ‘curl’ or ‘wget’ in that case).

The disk images contain interesting operating systems and software that run under the QEMU emulator. Some of them are well-known or not-so-well-known operating systems, old and new, others are custom demos and neat algorithms.

The ‘run’ scripts (and disk images if included in the download) were created by volunteers from the QEMU community to showcase cool software that QEMU can run.

https://www.qemu-advent-calendar.org/2018/

Animated GIF’s from Qemu

I found this one recently… So the first thing is you need Qemu 0.10 or higher (probably not a problem), as it’ll save in ppm format no issues.  Then the fun expect program (Yay Linux subsystem), and of course Imagemagik.

Run Qemu so you can telnet to the command monitor:

i386-softmmu\qemu.exe -L pc-bios -hda c:\temp\127disk.img -monitor telnet:127.0.0.1:23,server,nowait -hdb fat:\temp\dosb

I used this small program

#!/usr/bin/expect
set timeout -60
set capture 1
spawn telnet localhost
expect “(qemu)”
send “brake 1000\r”;
expect “(qemu)”
while { 1 == 1 } {
set fstring [format %04s $capture]
send “screendump /temp/$fstring.ppm\r”;
expect “(qemu)”
incr capture
sleep 3
}

and then to convert it into an animated gif:

d:\ImageMagick-7.0.7-18-Q16>convert -loop 0 -delay 100 \temp\*.ppm \temp\GHZ.gif

and behold:

Isn’t that great?

Qemu now supports the HPPA in softmmu mode!

I’ve worked on machines with HP-UX, but never owned one.  Well Qemu now has system emulation thanks to Richard Henderson! You can find information over at:

https://parisc.wiki.kernel.org/index.php/Qemu

Being the unfair person I am, I thought I’d try NeXTSTEP to see how far it gets.

Processor   Speed            State           Coprocessor State  Cache Size
---------  --------   ---------------------  -----------------  ----------
0      250 MHz    Active                 Functional            0 KB

Available memory: 512 MB
Good memory required: 16 MB

Primary boot path: FWSCSI.6.0
Alternate boot path: LAN.0.0.0.0.0.0
Console path: SERIAL_1.9600.8.none
Keyboard path: PS2

Available boot devices:
1. DVD/CD [lsi 00:00.0 2:0 Drive QEMU QEMU CD-ROM 2.5+]
2. lsi 00:00.0 0:0 Drive QEMU QEMU HARDDISK 2.5+

Booting from lsi 00:00.0 0:0 Drive QEMU QEMU HARDDISK 2.5+

Booting...
Boot IO Dependent Code (IODC) revision 153

HARD Booted.
Can't determine I/O subsystem type

NEXTSTEP boot v3.3.4.17
524288 memory

NEXTSTEP will start up in 10 seconds, or you can:
Type -v and press Return to start up NEXTSTEP with diagnostic messages
Type ? and press Return to learn about advanced startup options
Type any other character to stop NEXTSTEP from starting up automatically

boot:

And amazingly the bootloader works, although that is about it. Trying to boot up OpenBSD gets about this far:

PDC_CHASSIS: Initialize (3), CHASSIS  cec0
>> OpenBSD/hppa CDBOOT 0.2
booting dk0a:/bsd.rd: 2703360+851960+2675712+547840=0x8631f0


SeaBIOS: Unimplemented PDC_CACHE function 1 8ddad0 1 1 1

I found on Windows though that the Debian 8 CD’s work the best, as the earlier ones lock up after loading a kernel, and the later one doesn’t fully initialize.  I’ve been using this one: debian-8.0-hppa-NETINST-1.iso  Serial console interaction is the way to go, so I ran Qemu like this:

qemu-system-hppa.exe -L . -serial telnet:127.0.0.1:4444,server,wait -boot d -cdrom debian-8.0-hppa-NETINST-1.iso -hda Deiban8HPPA.vmdk

So this way I can get get the install kicked off.  Although I should probably have just downloaded debian-8.0-hppa-CD-1.iso

Linux on HPPA

Otherwise, yeah, it’s Linux, on HPPA

And for anyone who is interested, the only version of HP-UX I have hanging around, HP-UX 10.20 [HP9000 S700] gives me the following:

HP-UX 10.20 on Qemu

Mac OS X Server 1.0 installs on Qemu

OS X Server 1.2 on qemu single user mode

That’s right, the ADB is usable enough now to type and move the mouse, meaning that OS X Server can now be installed within Qemu!

It’s incredibly slow, and the mouse is incredibly jumpy, but it’s actually running!

Basically, like A/UX, you boot up into MacOS to partition the drive.

qemu-system-ppc-screamer.exe -L pc-bios -m 256 -M mac99 -prom-env “boot-args=-v” -prom-env “auto-boot?=true” -prom-env “vga-ndrv?=true” -hda 2GB.vmdk -cdrom “Mac OS X Server 1.2, MOSX_Booter.iso” -sdl -device usb-mouse -device adb-keyboard -boot d

OS X Server 1.2 MacOS 9 Create OS X Server partition

And then kick off the installer:

OS X Server 1.2 MacOS 9 Start Install

Which really isn’t much to do, other than tagging the partition, and prepping the machine to reboot.

It’s OK

Qemu doesn’t emulate the NVRAM, so it’ll complete with this ‘non fatal’ ‘fatal error’

After that, boot into the OS X Server kernel, and continue the install:

qemu-system-ppc.exe -L pc-bios -prom-env “boot-args=-v rd=sd0″ -drive file=2GB.vmdk,index=1,format=vmdk,media=disk -M g3beige -cpu g3 -drive file=”Mac OS X Server 1.2, MOSX_Booter.iso”,index=0,format=raw,media=cdrom -prom-env “boot-device=cd:9,\\:tbxi” -m 256 -net none

OS X Server 1.2 installing text mode

It will then format the disk, and copy over the base operating system.  After that it’s time to shutdown, and reboot the VM.  I couldn’t figure out a pure hard disk boot, but again using the CD-ROM, you can just tell it to pull the root from the hard disk.

qemu-system-ppc.exe -L pc-bios -prom-env “boot-args=-v rd=hd0″ -drive file=2GB.vmdk,index=1,format=vmdk,media=disk -M g3beige -cpu g3 -drive file=”Mac OS X Server 1.2, MOSX_Booter.iso”,index=0,format=raw,media=cdrom -prom-env “boot-device=cd:9,\\:tbxi” -m 256 -net none

OS X Server 1.2 installing

And after this, it’ll want to reboot again.  Launch it up and now we get the initial setup

Setup Assistant

And with that out of the way, we can logon!

And after a while, it’ll load up the desktop

OS X Server 1.2 Desktop

As mentioned above, the mouse is incredibly jittery.  Doing anything graphical is very difficult. But here we are, running OS X/Rhapsody for the PowerPC!

That’s all!

Because the mouse is VERY jumpy at the moment, Im going to make some pre-configured disk images available because running the disk tool under OS 9 is a major pain.  The first image has only been partitioned, while the second has completed the ‘text mode setup’, aka a minimal install.

And that’s it for now!

Revisiting a UnixWare 7.1.1 install on Qemu/KVM

So after nearly 8 years ago from messing around with UnixWare, I wanted to confirm something from a SYSV Unix that has a C compiler that isn’t GCC, and I remembered I have UnixWare 7.1.1 from a long time ago.  Anyways I have long since lost the virtual machine I had installed onto, but I still have media and of course the more important licenses.

unixware certificate of license and authenticity
UnixWare licenses. the dread of fixing things 20+ years later

Yep it’s the real thing.  So with my certs in hand I do an initial install in Qemu and on reboot the system basically has bricked itself.

WARNING: System is in an unreliable state.

And then looking at the licenses it turns out that my license has expired.  What?

Somehow I got lucky before, but it turns out that the installation process for ancient UnixWare is NOT Y2K compliant!  And this actually turned out to be a known issue.  I can’t find the original article, but a mirror is here: ischo.net

So basically install using an eval license, which will of course expire on install, and then use your actual license after the installation, remove the eval, reboot and all will be well.

License Number: UW711EVAL
License Code: airhorpx
License Data: d60;m7hjbtt

Now isn’t that great.

The OS install license immediately expires.

Although you can’t boot up in any real useful state, the networking will kick people off, and it’ll constantly complain that you are in license violation, you can at least bring up the SCO Admin tool, and add in your actual licenses, and then delete the evals.

And now we’re good!

Ok, now for the real fun part, flags and how to run with kvm/qemu.  Since I was loading this onto a server for remote access something like this works fine for me as I’m using the VNC remote console.

qemu-system-x86_64 -enable-kvm -m 1024 -smp 4 -hda UnixWare.vmdk -cpu pentium -net none -monitor telnet::444,server,nowait -curses -vnc 10.12.0.1:11 -cdrom iso/SCO_UnixWare711.iso

So the key things are to restrict the CPU level, and I’ve deferred the network configuration so I can update network drivers, and the OS.  I’ve found that by doing the networking during the install resulted in an OS that crashed with an integer divide by zero after installing the fixpack 5.

Once you have UnixWare 7.1.1 installed, be sure to install Maintenance Pack 5, which is thankfully still online over at sco.com  I’d also recommend to do this in single user mode, you can enter single user mode by hitting a key during the boot logo and typing in:

INITSTATE=S
boot

And you’ll boot in single user mode, and can install the Maintenance pack with ease.  Until the maintenance pack is installed, expect poor stability, and the system won’t actually listen to the real time clock device, and it’ll accelerate the clock like crazy where I was passing an hour every minute or two.

Adding the AMD PCnet on UnixWare

Once the install and update is done, I just added a PCI network card (So older versions of Qemu work well with the ne2k_isa, but newer work much better with the AMD PCNet card.), which is a popular choice for both machines and VM’s of the era.  Although you can use SLiRP the built in NAT for Qemu/KVM alternatively you can also use tun/tap.  I tried to enable SMP, however it has issues binding to the other processors, although it does see them.  And this is better to give full access to the network stack for fun things like FTP, NFS and whatnot.

qemu-system-x86_64 -enable-kvm -m 1024 -smp 4 -hda UnixWare.vmdk -cpu pentium -monitor telnet::444,server,nowait -curses -vnc 10.12.0.1:11 -device pcnet,netdev=net0 -netdev tap,id=net0,ifname=tap10,script=/etc/qemu-ifup

Telnet access

And just like that I can now access the VM.

And for fun…

# uname -a
UnixWare kvm711 5 7.1.1 i386 x86at SCO UNIX_SVR5
# uname -f
architecture=IA32
bus_types=PCI2.10,ISA,PnP1.0
hostname=kvm711.joes.local
hw_provider=Generic AT
hw_serial=DEM076116
kernel_stamp=04/11/11
machine=Pentium
num_cg=1
num_cpu=1
os_base=UNIX_SVR5
os_provider=SCO
release=5
srpc_domain=
sysname=UnixWare
user_limit=5
version=7.1.1

Oh yeah so I don’t forget years from now I’m using the following OS & Qemu version:

# qemu-system-x86_64 -version
QEMU emulator version 2.8.1(Debian 1:2.8+dfsg-6+deb9u3)

# cat /etc/issue
Debian GNU/Linux 9 \n \l

Also I found an eval serial for SMP, but it doesn’t recognize the second processor after the boot.

# psrinfo -v
Status of processor 0 as of 01/31/18 16:40:07
Processor has been on-line since 01/31/18 16:13:57.
The Pentium processor has a i387 floating point processor.
The following conditions exist:
Device drivers are bound to this processor.

I’ll try apparently this as for some reason it doesn’t detect the MP in Qemu/KVM so it never installed the osmp driver.

pkgadd -d cdrom1 osmp

Add the following line to the file /stand/boot:
ACPI=Y