[Qemu-discuss] FYI: XP SP3 32b, QEMU/KVM, Debian Jessie 64b - recent experience

[Frantisek Rysanek]

Dear fellow QEMU users,

I'm posting this mostly "for the record" - for people trying the same 
thing later on.

As it's becoming ever more difficult to get hardware, on which XP is 
willing to run natively and be any use (see the timestamp in the 
header of this message), and as we have customers who insist
on keeping XP going on, I've decided to investigate some 
virtualization possibilities... 
The hardware I used in my tests is a cool-running quadcore BayTrail 
fanless box, on which Windows require a forced non-ACPI HAL to even 
boot, on a single core, without any HW-specific drivers available.
As the OS basis I used Debian 8 (8.2 I guess) 64b and I installed 
KVM, Qemu and some other bits from the Debian release repositories.
Later on also iasl when playing with seabios, and libvirt for virsh.
Actually I played with iasl and seabios source on Jessie 32b, on 
another machine that I use as a "build environment".
Right from the start I've been running qemu using the explicit
shell command, just wrapped in a shell script to make tweaking of the 
cmdline args easier / more manageable.

I didn't manage to start QEMU on my first attempt, so I gave up
and resorted to VirtualBox, earning approval and praise from my 
clickety colleagues ("it must work without explicit config, or it's 
not worth the bother" and "VirtualBox works on Windows and Mac").
I noticed that Virtualbox insists on emulating an IDE HBA and some 
real-world NIC, and does present an XP-compatible ACPI interface, to 
the point that XP do detect the configured number of CPU cores, and 
does show them as objects in the device manager tree. The install 
(from a CD image file) took an unsurprising time, on par with 
CD-based installation on bare metal - and the resulting performance 
is "just your normal XP" - a little lazy. One useful feature: the 
VirtualBox window doesn't "arrest your mouse".

I later returned to QEMU. It turned out that I got stuck at the
disk drive specification - had to try various options to finally
get a workable config. Next, I got stuck at ACPI support.
No go. I quickly realized that I can install and run XP
with an MPS HAL (press F5 when the XP installer asks for F6), 
but initially XP ran with a single CPU core, despite my attempt to 
configure 2 cores, 1 thread per core, 1 socket. I spent a few hours 
in vain, trying to make ACPI work. I tried several binary seabios 
builds from 1.7.0 up, then I tried to build my own from upstream 
seabios tarballs, then I tried a few things using GIT, then I 
downloaded a newer debianese src package for seabios 1.7.5-1, which 
contains some patches in the build scripts to work with the new 
iasl... tried copying over the .dsl files from 1.7.2 and reverting 
seabios patch 
2114f50148c42e374586359d23b522483ca10e8d
(manually), but none of that worked - error a5 all the way, no matter 
what I did. 
In the end, I discovered a particular format of -smp, which results 
in XP detecting two cores :-) even with the MPS HAL.
Two cores show up in the Windows task manager (two CPU load charts 
side by side), and I don't mind that the device manager doesn't show 
any CPU objects in the tree - they're no practical use anyway.
Also, XP cannot shut down the VM - doesn't have ACPI
to call and is not willing to use APM for some reason
(err... is this available? not sure... never mind...)

Here are some pitfalls for the noob that I discovered in the config:

Disk drives / HBA emulation:
-drive if=ide didn't work for me.
-drive if=virtio didn't work for me, either - a CD-ROM image of the 
XP installer, presented with this option, failed to boot - and the 
virtio guest drivers (downloaded from RedHat) seemd to hang on driver 
load, even for hard drives. Makes me wonder if virtio requires 
additional host-side preparation (via libvirt, possibly - never got
down to it, not much motivation).
-drive if=scsi worked like a charm.
Surprisingly to me, the SCSI HBA emulation (some old LSI model) is 
actually pretty fast. My explanation is, that it might actually be 
pretty easy to emulate a well designed SCSI HBA. Pass this block out, 
pass this block in, DMA is easy to emulate, can be mapped straight 
onto the SCSI guts in Linux if needed (though I was using a regular 
file on top of EXT4 as a HDD image). The SCSI emulation is possibly
limited to LBA32 = 2 TB per disk with a 512B block size.
Makes me wonder if XP can do any better anyway :-)

Once I figured out the "press F5" trick to load the "MPS 
multiprocessor PC" HAL, even while I still had a single CPU core in 
the guest, the XP install on top of SCSI-emulated CD and HDD ran 
pretty fast - fastest I've ever seen. Remember the several installer 
bargraphs that you have to watch? Well they didn't exactly ZIP away, 
but at least they did visibly move along, which is good, if you 
remember what they look like on bare metal with a physical CD-ROM 
drive. The whole initial install process may have taken like 10 
minutes.
=> this is a pretty far cry from earlier reports that you can find 
using Google, about XP installs taking half a day in QEMU!
This was possibly on hardware-emulated IDE in PIO mode,
at a time when IDE emulation still worked, and without KVM
cooperating in the kernel - I have no other explanation.
Once I got the showstopper pitfalls sorted out, the speed of the XP 
install was quite a shock.

The trick to get more than one CPU, is to use the simple (probably 
legacy) syntax of -smp: don't care about cores, threads and sockets; 
to get 2 CPU cores in XP, just use 
  -smp 2
That's all there is to it.
On the host machine, you should see QEMU eat 100% of the CPU's thus 
allocated. Not sure if the HLT, performed by the XP's process 
scheduler when idle, makes it through to the linux host side 
scheduler, i.e. if the CPU cores actually get to know that they're 
supposedly idle, and save some juice... I didn't bother to 
investigate on the BayTrail CPU with its 5-10W TDP.

All along I was glinting at virtio - for disks and for net, possibly 
some "passthrough accelerated" graphics as well. But never made it to 
work. I noticed that virtio network does work from VirtualBox, once 
you install libvirt and start libvirtd (no further config preparation 
apparently necessary) and virsh shows VirtualBox domains.
But none of this worked for Qemu. Based on some hints in the official 
docs on Qemu/KVM/libvirt and possibly elsewhere, I would have to 
"start qemu through libvirt", meaning I would have to resort to the 
ugly XML config files, and specifically for qemu, I'd have to refer 
to a special DTD to get the qemu cmdline args in the XML file... does 
that QEMU DTD URI, pointing to someplace on the interwebs, actually 
mean that I won't start my emulated XP VM without internet access, or 
when that site is down? And that's exactly where I dumped the whole 
libvirt and virtio. Too much pain just to get virtio to work 
(possibly, it's just my guess), when the "emulated hardware" approach 
actually seems to work fairly well... Let me know if there's a way to 
do this from bare shell, without the ugly XML havoc.

I'm attaching two scripts that I used to tweak the install 
environment vs. the "normal operation" scenario. Pretty much the only 
difference should be the mapping of drives.
The shell scripts show some varieties of the options I was trying 
(environment variables commented out). 

The hands-on feel of XP with a single CPU core was "just normal", and 
once I got two CPU's to work, it actually felt pretty snappy - except 
for the emulated VGA graphics of course... but even that wasn't all 
bad, seems like there is some blitter passthrough in play as well, in 
the emulated Cirrus adapter. I did turn off the window shades and 
animations. I did not try to benchmark anything, not even
CPU performance.

In case anyone ever wants me to install XP on modern hardware in this 
way (in a Qemu sandbox on top of Linux), he may want to run the VM
full screen, to get a "native" feel (no punkster XWindows decorations 
seeping through at the edges of the XP desktop). I just hazard a 
guess that I could arrange that by running SDL over svgalib on bare 
metal VGA hardware (or some such), or by starting a bare Xserver and 
ask the single QEMU "app" to render to the bare Xserver via SDL in 
full screen mode. That would be a neat trick from the command line.
Or, in some cases the user doesn't actually need an XP GUI on the box 
- I've had cases where the XP box was just converting data from some 
serial line fieldbus to Ethernet or some such. In that case, I could 
tell QEMU to run the VM headless, or to render VGA into a VNC 
server... so the box in the rack somewhere would only show a Debian 
text-mode login prompt :-)

XP will be completely dead once Microsoft stops the activation 
service. Even then, those who are not afraid can install XPe,
possibly violating the license, once new licences are no longer 
available for purchase.
This story also proves to me, that instead of fighting XP-to-metal 
compatibility, from now on we'll instead be figting on two fronts:
XP-to-HV and HV-to-metal. So much for the "virtualization to liberate 
us forever".

So there you have it. Any follow-ups / comments are welcome.

Have a nice day everyone :-)

Frank Rysanek

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  qemu_install_xp.sh
     Date:  9 Dec 2015, 15:54
     Size:  1524 bytes.
     Type:  Unix-text

qemu_install_xp.sh
Description: Binary data

The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.

   ---- File information -----------
     File:  qemu_run_xp.sh
     Date:  9 Dec 2015, 15:45
     Size:  1470 bytes.
     Type:  Unix-text

qemu_run_xp.sh
Description: Binary data