Skip to content
BrainwreckedTech edited this page Feb 15, 2022 · 32 revisions

Settings Research Documentation

This is largely documentation of the --pcfrom option and why decisions were made they way that they were.

HVF/KVM Accelleration

HVF/KVM Accelleration causes problem with older code. Since the "turn-around" for safe usage is 2000, qcl won't enable KVM acceleration by default until --pcfrom 2001 is used. The options --nohvf, --nokvm, --usehvf, and --usekvm can be used to override decisions made by qcl. (HVF and KVM are synonymous to qcl -- it will use the appropriate accelerator for the platform it's running on.)

Operating System RTR KVM Problems
Windows 95 1995 Assumed from Windows 98
Red Hat Linux 5.0 1997 Hangs the cirrus driver
Windows 98 1998 Crashes NDIS (networking)
Turbo Linux 6.0 2000 Hangs the cirrus driver. Hangs LILO.
Windows 2000 2000 No problems
Mandrake Linux 8.1 2001 No problems
Fedora Core 1 2003 No problems
SuSE Linux 9.3 2005 No problems
Ubuntu 6.06 LTS 2006 No problems
Ubuntu 6.10 LTS 2006 No problems
Windows Vista 2007 No problems
Ubuntu 7.04 LTS 2007 Hangs the kernel boot
Ubuntu 7.10 LTS 2007 No problems
Ubuntu 8.04 LTS 2008 No problems

CPU selection

CPU parameters are pretty much an exact reflection of what was available at the time. Operating systems give a large leeway to the processors they run on.

QEMU does not provide a pentium4 option. This is probably due to the then-exclusive (i786/pentium4) instruction set not seeing much use in the 32-bit space, with everyone sticking with the Pentium III (i686) instead. The Pentium 4 was released in 2000, and Hyper Threading was introduced in 2004. But with no pentium4 target in QEMU, there is a bit of a gap.

(The i786/pentium4 instruction set sees full use in all 64-bit CPUs as they are part of the x86_64_v1 spec.)

While AMD released the AMD Athlon 64 in 2003, there is no ahtlon64 target. There is an athlon target, but it's the original 32-bit one from 1999. The next-best thing from QEMU is Opteron_G1.

As far as the athlon target is concerned, that's passed on in favor of Pentium III since AMD has announced that it even they will be dropping 3DNow! instructions from their future processors.

Core count clamping is based on real consumer hardware. For Windows 95/98/ME, this really should not be overridden as they were never designed with SMP in mind. Windows 2000 was designed with SMP in mind. but the Professional version is restricted to 2 CPUs. (The concept of multi-core CPUs was not a thing when Windows 2000 was released, so the only way to do SMP was more CPUs.) Older Linuxes will also not support SMP if that wasn't a thing when the OS was released. (There will usually be an SMP kernel option if your legacy Linux distro supports it.)

Keep in mind that qcl will only "clamp" core counts. This means that if auto-detection suggests running with 4 cores, it will not bump up the core count to 12 because you want to run a Westmere or later CPU. But if you want to run a pentium3 CPU, qcl will take that 4-core auto-detection and bump it down to 1.

You can force a core count with --cores <n> if you do not like what qcl suggests.

Year CPU Cores
1993 pentium 1
1997 pentium2 1
1999 pentium3 1
2004 Opteron_G1 1
2006 Conroe 2
2007 Penryn 4
2008 Nahalem 8
2010 Westmere 12
2011 SandyBridge 12
2013 Haswell 12

VirtIO was introduced in 2013, so hardware targeting stops here in favor of using VirtIO.

RAM Capacity

qcl tries to represent what was available at the time while also considering OS limitations.

Windows 95/98/ME all have a bug that occurs when there's 480MB or more of RAM.

Year Low Max 2nd Highest Max Max Max qcl default
1995 64MB 64MB 64MB 64MB
1996 64MB 128MB 512MB 128MB
1997 128MB 256MB 512MB 256MB
1998 128MB 384MB 512MB 384MB
1999 256MB 768MB 1GB 448MB
2000 384MB 768MB 1.5GB 768MB
2001 768MB 1GB 1.5GB 1GB
2002 1GB 1.5GB 1.5GB 2GB
2003 2GB 3GB 4GB 3GB
2004 4GB
2005 8GB

After 2005 qcl sets the RAM limiter to 999999999

GPU Selection

While choosing a CPU can be done largely independent of the operating system in use, GPU selection relies more on what drivers operating sytems bundled at the time. Unfortunately, QEMU does not offer much in the way of emulating real hardware. The ati-vga options are mostly aimed at Macs and are rendered moot as options by VESA (VGA) support.

While Windows can technically run with QEMU's VGA, graphics rendering is done by a "fallback" VGA driver that is extremely slow and limited up through Windows XP. Windows Vista has proper VESA support.

Early Linux support for QEMU's VGA can be even worse. While it does run, the resolution is extremely low (320x240). Proper support of QEMU's VGA comes with the vesa driver in XFree86.

Ubuntu vesa support is puzzling. When it works, it defaults to gigantic resolutions. When it doesn't, the VM hangs. In the latter case, switching over to cirrus-vga solves the problem. To be honest, Canonical is known for patching the holy bejeezus out of everything. This includes patches made for compatibility with arcane architectures they choose to support over Debian. And instead of limiting that patch to that architecture, the patch will carry over to the mainstream platforms as well for the sake of "consistency". The bochs_drm kernel module is a sore example of this, being patched out for all platforms because ppc64le doesn't like it.

Operating System RTR kernel X cirrus-vga ati-vga
rage128p
vmware-svga ati-vga
rv100
VGA
Windows 95 1995 πŸ†— πŸ•™ πŸ•™ πŸ•™ πŸ•™
Red Hat 5.0 1997 2.0.32 N/A πŸ’© πŸ•™ πŸ•™ πŸ•™ πŸ•™
Windows 98 1998 πŸ†— πŸ•™ πŸ•™ πŸ•™ πŸ•™
Turbo Linux 6.0 2000 2.2.14 3.3.6 πŸ’© ❌ ❌ πŸ•™ πŸ•™
Windows 2000 Pro 2000 πŸ†— ❌ ❌ πŸ•™ πŸ•™
Windows XP 2001 πŸ†— ❌ ❌ ❌ πŸ•™
Mandrake 8.1 2001 2.4.8 3.3.6 ⚠️ ❌ ❌ πŸ•™
Arch Linux 0.1 2002 2.4.18 4.2.0 πŸ†—
Fedora Core 1 2003 2.4.22 4.3.0 πŸ†— πŸ’© πŸ†— πŸ’© πŸ†—
SuSE 9.3 Pro 2005 2.6.11 6.8.2 πŸ†— ❌ πŸ†— ⚠️
Ubuntu 6.06 LTS 2006 2.6.15 7.0.0 πŸ†— ❌ πŸ†— ❌ πŸ†˜
Ubuntu 6.10 2006 2.6.17 7.1.1 πŸ†— ❌ πŸ†— ❌ ❌
Windows Vista HP 2007 ⚠️ ❌ ⚠️ ❌ πŸ†—
Ubuntu 7.04 2007 2.6.20 1.3 πŸ†— ❌ πŸ†— ❌ ❌
Ubuntu 7.10 2007 2.6.22 7.2.0 πŸ†— ❌ πŸ†— ❌ ❌
Ubuntu 8.04 LTS 2008 2.6.24 1.4.0 πŸ†— ❌ πŸ†— ❌ πŸ†˜

πŸ•™ = OS pre-dates GPU
❌ = No drivers / does not work at all
πŸ’© = Card supported but emulation flawed
πŸ†˜ = Card works but needs help
⚠️ = Uses wrong driver, but works
πŸ†— = Fully works.

Linux Support

Linux support can be tracked back to when modules first appear in the kernel or Xorg git repositories. Unfortunately, there are transitions that makes complete reverse traversal impossible. The Linux kernel moved to git in 2005. And Xorg split from XFree86 starting in 2003. So tracking anything before these dates relies on copyright notices and actually running code.

Note that the Linux kernel not having a driver isn't necessarily a show stopper. Most often this results in the kernel using a standard 80x25 text display. With a DRM driver the cosnole will expand to the native resoultion of the monitor. What most people will care about is XFree86/Xorg not having the driver.

Some additional pain: Just because the driver was written doesn't mean that distributions compiled the driver into their version of XFree86. This seems to be less of a problem when the switch to Xorg took place, and Xorg started work on modular-izing the source code.

GPU kernel Xorg
CL GD-5446 Β©1999 - ?.?.?? - cirrus.ko πŸƒβ‰€1997 - ≀4.1.0 - cir
Rage 128 Pro Β©1999 - ?.?.?? - aty128fb.ko Β©1999 - ?.?.? - r128
Radeon 7000 Β©2000 - ?.?.?? - radeon.ko Β©2000 - ?.?.? - ati
VGA βœ”2013 - 3.14 - bochs[_drm].ko Β©2000 - ?.?.? - vesa
VMWare SVGA βœ”2009 - 2.6.33 - vmwgfx.ko Β©1998 - ?.?.? - vmware

πŸƒ = Date based on running code
Β© = Date based on copyright
βœ” = Date based on git history

Networking

Networking also relies on OS support. While Windows support for NE2000 is good, Linux support for the card is bleh. Good NIC support between the two starts with the AMD PCnet card. The Realtek 8139 also has good support on both Linux and Windows.

qcl uses ne2k_pci up to --pcfrom 1996 and uses pcnet for --pcfrom 1997 and --pcfrom 1998

qcl implements rtl8139 starting with --pcfrom 2000

These choices can be overridden with the --ne2k, --pcnet, and --realtek options.

Operating System RTR ne2k_pci
1988
pcnet
1996
rtl8139
1999
e1000e
2013
Windows 95 1995 πŸ†— πŸ•™ πŸ•™ πŸ•™
Red Hat 5.0 1997 ❌ πŸ†— πŸ•™ πŸ•™
Windows 98 1998 πŸ†— πŸ†— πŸ•™ πŸ•™
Turbo Linux 6.0 2000 ❌ πŸ†— ❌ πŸ•™
Windows 2000 Pro 2000 πŸ†— πŸ†— πŸ†— πŸ•™
Windows XP 2001 πŸ†— πŸ†— πŸ†— πŸ•™
Mandrake 8.1 2001 πŸ†— πŸ†— πŸ•™
Arch Linux 0.1 2002 πŸ•™
Fedora Core 1 2003 πŸ†— πŸ†— πŸ•™
SuSE 9.3 Pro 2005 πŸ†— πŸ†— πŸ•™
Ubuntu 6.10 2006 πŸ†— πŸ•™
Windows Vista HP 2007 ❌ ❌ πŸ†— πŸ•™
Ubuntu 7.04 2007 πŸ†— πŸ•™
Ubuntu 7.10 2007 πŸ†— πŸ•™
Ubuntu 8.04 LTS 2008 πŸ†— πŸ•™

Pointing Device

On Windows, support for tablet devices starts with Windows 2000. It works as expected, end of story. Delightfully boring.

For Linux, the story is a bit more interesting. (Some might say evil.)

You can pretty much tell when there is zero tablet support because mouse tracking is...frustrating. Tracking always picks up where it left off. This means that if you exited bottom-left and re-enter top-left, the mouse cursor is still at the bottom-left of the screen. Moving up in this situation leads to the host's cursor leaving the top of the window, and leaving the guesn'ts mouse cursor in a slightly-higher place than before. Even more frustrating, mouse tracking isn't 1:1 with the guest. This leads to edge run-ins where the guest's cursor runs into the screen edge while the host's mouse cursor "plays catch-up".

That's not the evil part. The same goes for Windows 95 and 98, and the beahvior is bad enough to clue you into the fact that something isn't right. The evil part is "partial support". This is when your mouse cursor can jump as you exit and re-enter the guesn't screen, but tracking still isn't 1:1 with the host so you still get edge run-ins. What you are witnessing in this instance is wacom support. This X mouse driver allows for those jumps but its tracking is still not 1:1 with the host.

Full Linux support for the QEMU tablet device comes with the vmmouse driver for X. With this driver, the guest's mouse cursor will track the host's mouse cursor 1:1, resulting in completely expected behavior as the host's mouse cursor enters and exits the guest's display.

Given that Fedora Core 1 loses all mouse movement with usb-tablet, qcl doesn't enable that device until --pcfrom 2004. If further testing proves Fedora Core 1 to be more of an outlier then qcl will enable usb-tablet earlier as appropriate.

The pointing device qcl chooses can always be over-ridden with --mouse and --tablet.

The End Result

Year Machine KVM CPU SMP RAM Storage SCSI Card GPU NIC Mouse Sound
1995 pc ❌ 486 1 64MB F/I/S am53c974 cirrus-vga ne2k PS/2 sb16
1996 pc ❌ pentium 1 128MB F/I/S am53c974 cirrus-vga ne2k PS/2 sb16
1997 pc ❌ pentium2 1 256MB F/I/S am53c974 cirrus-vga pcnet PS/2 sb16
1998 pc ❌ pentium2 1 384MB F/I/S am53c974 cirrus-vga pcnet PS/2 sb16
1999 pc ❌ pentium3 1 448MB F/I/S dc390 cirrus-vga pcnet PS/2 sb16
2000 pc ❌ pentium3 1 768MB F/I/S dc390 cirrus-vga rtl8139 PS/2 ac97
2001 pc β­• pentium3 1 1GB F/I/S dc390 cirrus-vga rtl8139 PS/2 ac97
2002 pc β­• pentium3 1 2GB F/I/S dc390 VGA rtl8139 PS/2 ac97
2003 pc β­• pentium3 1 3GB F/I/S dc390 VGA rtl8139 PS/2 ac97
2004 pc β­• Opteron_G1 1 4GB F/I/S dc390 VGA rtl8139 usb-tablet ac97
2006 pc β­• Conroe 2 8GB F/I/S dc390 VGA rtl8139 usb-tablet ac97
2007 pc β­• Penryn 4 ♾️ F/I/S dc390 VGA rtl8139 usb-tablet ac97
2008 pc β­• Nehalem-IBRS 8 ♾️ F/I/S dc390 VGA rtl8139 usb-tablet ac97
2009 q35 β­• Nehalem-IBRS 8 ♾️ F/I/S/A dc390 VGA rtl8139 usb-tablet ich9-intel-hda
2010 q35 β­• Westmere-IBRS 12 ♾️ F/I/S/A dc390 VGA rtl8139 usb-tablet ich9-intel-hda
2011 q35 β­• SandyBridge-IBRS 12 ♾️ F/I/S/A dc390 VGA rtl8139 usb-tablet ich9-intel-hda
2012 q35 β­• InvyBridge-IBRS 12 ♾️ F/I/S/A dc390 VGA rtl8139 usb-tablet ich9-intel-hda
2013 q35 β­• Haswell-IBRS 16 ♾️ F/I/S/A dc390 VGA e1000e usb-tablet ich9-intel-hda
Clone this wiki locally