Re: [debian-hppa] qemu-system-hppa and Debian HPPA
Helge Deller <[email protected]>
| Newsgroups | gmane.linux.ports.parisc,gmane.linux.debian.ports.hppa |
|---|---|
| Message-ID | <[email protected]> |
On 8/14/21 3:34 PM, Nelson H. F. Beebe wrote: > This is a report of failures, and ultimate success, in installing > Debian HPPA with the QEMU emulation of that CPU architecture. > > I run a large farm of more than 500 physical and virtual machines that > we use for software testing and development. The VMs include numerous > O/Ses and CPU types: AMD64 (x86_64), ARM32, ARM64, Alpha, M68K, > MIPS32, MIPS64, PowerPC, RISC-V64, S390x, SPARC, and x86. Most of > those are emulated by QEMU running on CentOS 7 and Ubuntu 20.04 on > Intel Xeon hardware. > > The major historical CPU family with IEEE 754 floating-point > arithmetic missing from that list is Hewlett-Packard's Precision > Architecture RISC, PA-RISC, also called HPPA. In the 1990s, we had > several physical workstations and servers of that type, but all have > long since been retired and disposed of. > > Neither of our other virtualization systems, OVirt and VirtualBox, > supports emulation of other CPU types. With VirtManager and QEMU, > however, there are numerous CPU types available. Regrettably, for many > of them, it is necessary to discard the easy-to-use VirtManager GUI, > and resort to low-level qemu-system-xxx command lines, and that is the > case for Alpha, HPPA, M68K, and SPARC. > > One of the projects that I work on is ensuring that the annual TeX > Live releases can be built on a wide range of platforms. This year's > report is at > > http://www.math.utah.edu/pub/texlive-utah/ > > I had previously tried to install Debian 4, 5, 9, and 10 releases for > HPPA, but each time, I failed: either QEMU complained of missing > firmware, or the VM would not boot, or it would boot, but I could not > get a working network. > > In June 2021, I retried with a .qcow2 disk image converted from > > -rw-rw-r-- 1 511504481 May 9 2018 debian-10-hdd-img.tar.bz2 I think this is the one I prepared once: http://backup.parisc-linux.org/qemu/debian-10-hdd-img.tar.bz2 > That disk image is far too small for my needs, but I was able to to > extend the partition size like this: > > qemu-img convert -O qcow2 debian-10-hdd.img debian-10-hdd.qcow2 > qemu-img resize debian-10-hdd.qcow2 +55G > > That gets a bigger partition, but further work is needed after a boot > from an ISO image: > > fdisk /dev/sda > [delete second partition, then recreate with maximum size] > reboot > > Unfortunately, the disk image it has no C/C++ compilers, and other > tools that I need, (e.g., starting with the build-essential one) but > we found that it is sufficiently old that it is impossible to run "apt > update" and "apt install" commands: there are far too many unresolved > dependencies. debian-unstable for hppa is a moving target. And we had lots of fixes since then. So, yes maybe updating is not easy. > It would be good to get that .img file replaced by a current one that > could be used directly, and that had important packages needed for > software development already installed, Ok, I'll see if I do another one soon. > including build-essential, > gfortran, m4, and compilers for Go and Rust. I don't think we have a Go-port yet, and for Rust only initial porting was done by Adrian Glaubitz for gcc-rust: https://www.mail-archive.com/[email protected]/msg00028.html > This month, I tried an install from the more recent ISO image > > -r--r--r-- 1 263258112 Jun 8 16:14 debian-10.0.0-hppa-NETINST-1.iso That's a newer debian install CD I think. > With the native version 4.2.0 qemu-system-hppa on Ubuntu 20.04 LTS, > the installer boot died with > > [ 51.098263] [<101e7684>] do_group_exit+0x54/0xf0 > [ 51.098263] [<101f76a4>] get_signal+0x1b0/0xac8 > [ 51.098263] [<101c5b34>] do_signal+0x4c/0x56c > [ 51.098263] [<101c609c>] do_notify_resume+0x48/0xfc > [ 51.098263] [<101b70a8>] intr_check_sig+0x34/0x38 > [ 51.098263] > [ 51.098263] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000a ]--- > > I have built several later versions of QEMU from source, but with > them, the installer runs for some time, then dies with a terminal > screen that looks like this: > > [ (1*installer) 2 shell 3 shell 4- log ][ Aug 07 0:00 ] > .... blank screen ... > [ 1489.609145] _______________________________ > [ 1489.609145] < Your System ate a SPARC! Gah! > > [ 1489.609145] ------------------------------- > [ 1489.609145] \ ^__^ > [ 1489.609145] (__)\ )\/\ > [ 1489.609145] U ||----w | > [ 1489.609145] || || > [ 1489.613720] ip (pid 2962): Illegal instruction (code 8) > [ 1489.614573] CPU: 0 PID: 2962 Comm: ip Tainted: G E 5.10.0-6-parisc #1 Debian 5. > [ 1489.694519] ---[ end trace 49060643616260b7 ]---844cx2744 E 5.10.0-6-parisc #1 Debian 5. > > For the record, here is the emulator command: > > $QEMUDIR/qemu-system-hppa \ > -m 3G \ > -drive file=debian-10e-hdd.qcow2 \ > -drive file=debian-10.0.0-hppa-NETINST-1.iso,media=cdrom \ > -boot order=d \ > -nographic \ > -serial mon:stdio > > I ran an xterm log of those attempts, and found that the "Your System > ate a SPARC! Gah!" message appears just after the output > > Detecting network hardware > > That suggested that changing from the default TULIP network device > might be worth trying. > > The devices supported by qemu-system-hppa are > > e1000 i82559c > e1000-82544gc i82559er > e1000-82545em i82562 > i82550 i82801 > i82551 ne2k_pci > i82557a pcnet > i82557b rtl8139 > i82557c tulip > i82558a virtio-net-pci > i82558b virtio-net-pci-non-transitional > i82559a virtio-net-pci-transitional > i82559b vmxnet3 > > Of those, the Intel e1000 is one that is commonly supported on most > operating systems. > > I therefore changed the startup command to > > $QEMUDIR/qemu-system-hppa \ > -m 3G \ > -drive file=debian-10e-hdd.qcow2 \ > -drive file=debian-10.0.0-hppa-NETINST-1.iso,media=cdrom \ > -boot order=d \ > -nographic \ > -serial mon:stdio \ > -net nic,model=e1000,netdev=net0 \ > -netdev user,\ > id=net0,\ > net=192.168.123.0/24,\ > restrict=off,\ > ipv6=off,\ > hostfwd=tcp::12222-192.168.123.122:22 > > and that led to a successful boot of the installer, which ran to > completion, but took more than 10 hours to do so. Newer versions of qemu have a tulip driver. This works best. > In my recent experiments, I have used QEMU versions 6.0.0, 6.1.0-rc0, > 6.1.0-rc2, and 6.1.0-rc3. > > Although the ISO image is labeled as Debian version 10, the actual > version reported in /etc/debian_version is 11.0. It's a debian-unstable install CD, so 11. > I can now boot the .qcow2 image directly with a similar command > > $QEMUDIR/qemu-system-hppa \ > -m 3G \ > -smp cpus=4 \ > -drive file=debian-10e-hdd.qcow2 \ > -boot order=c \ > -nographic \ > -serial mon:stdio \ > -net nic,model=e1000,netdev=net0 \ > -netdev user,\ > id=net0,\ > net=192.168.123.0/24,\ > restrict=off,\ > ipv6=off,\ > hostfwd=tcp::12222-192.168.123.122:22 > > where the -drive line for the ISO image is removed, and the boot > device is changed from d to c. > > My local practice is that VMs reside on the private network > 192.168.123.0/24, and the last octet for a particular VM prefixes the > standard secure shell port number, 22: thus, I have port 12222 when > the last octet is 122. > > The network used by QEMU, and its DHCP range, is determined by this > block in /etc/libvirt/qemu/networks/default.xml: > > <network> > <name>default</name> > <uuid>740f7e29-7ab4-4130-9316-d2e216fa707b</uuid> > <forward mode='nat'/> > <bridge name='virbr0' stp='on' delay='0'/> > <mac address='52:54:00:7c:1e:ae'/> > <ip address='192.168.123.1' netmask='255.255.255.0'> > <dhcp> > <range start='192.168.123.241' end='192.168.123.254'/> > </dhcp> > </ip> > </network> > > I can now connect to the VM with > > ssh -p 12222 localhost > > and have since been able to fully configure it with user accounts and > installations of scores of packages. So far, it appears to run > stably. > > There is, however, a serious performance issue that I will discuss in > a subsequent posting to this list. The PA emulation isn't very fast, but not bad either. On my not-so-fast x86 it's performing like a native j5600 machine. If your emulation is slow, I'd suggest that you: 1. add "accel tcg,thread=multi" to the qemu line. This enables that every emulated CPU runs in an own qemu thread, so "-smp cpus=4" should run on 4 physical CPUs on your host. You can check with "top" on the host if multiple CPUs are used. 2. Make sure you have debug code disabled when you compile qemu. If enabled it generates very slow running qemu. 3. You used "nographic", so it's not relevant in your case, but if you would enable graphics you should add "-display sdl". It's a whole lot faster than the default setting. Some additional info is here: https://parisc.wiki.kernel.org/index.php/Qemu Helge