-
Notifications
You must be signed in to change notification settings - Fork 1
Home
This is largely documentation of the --pcfrom option and why decisions were made they way that they were.
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 | 2003 | No problems |
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.
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
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.
| Operating System | RTR | cirrus-vga | ati-vga model=rage128p |
ati-vga model=rv100 |
VGA |
|---|---|---|---|---|---|
| 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 | 🆗 | 🆗 | 🆗 |
❌ = No drivers / does not work at all • 🕙 = OS pre-dates GPU • 💩 = Card supported but emulation flawed • 🆗 = Fully works.
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 | 🆗 | 🆗 | 🕙 |
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.