-
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 | 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 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.
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
π = Fully works.
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 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
through --pcfrom 2000
qcl
uses rtl8139
starting with --pcfrom 2001
These choices can be overridden with the --ne2k
, --pcnet
, and --realtek
options.
Operating System | RTR | ne2k_pci 1988 |
pcnet 1996 |
rtl8139 1999 |
e1000e 2013 |
Notes |
---|---|---|---|---|---|---|
Windows 95 | 1995 | π | π | π | π | |
Red Hat 5.0 | 1997 | β | π | π | π | |
Windows 98 | 1998 | π | π | π | π | |
Turbo Linux 6.0 | 2000 | β | π | β | π | Realtek 8139 detected but doesn't work |
Windows 2000 Pro | 2000 | π | π | π | π | |
Windows XP HE | 2001 | π | π | π | π | |
Mandrake 8.1 | 2001 | π | β | π | Realtek 8139 detected but doesn't work | |
Arch Linux 0.1 | 2002 | π | ||||
Fedora Core 1 | 2003 | π | π | π | ||
SuSE 9.3 Pro | 2005 | π | π | π | ||
Ubuntu 6.10 | 2006 | π | π | |||
Windows Vista HP | 2007 | β | β | π | π | NE2000 and PCnet no longer included |
Ubuntu 7.04 | 2007 | π | π | |||
Ubuntu 7.10 | 2007 | π | π | |||
Ubuntu 8.04 LTS | 2008 | π | π |
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
.
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 |