"One *major* problem with virtualizers is that they uniformly use an existing CPU identifier, even though they might have their own sets of bugs. This makes it much harder to work around bugs in them."
You can still have a virtual machine which provides a slightly different environment inside the VM than you'd find on the bare metal, and virtualize a "vanilla" OS just fine. IBM's VM, for instance, has a special instruction which traps to the hypervisor for various services. It's a well-known technique, and provided that it doesn't alter any existing code's ability to run, shouldn't cause any real problems.
It's ok for the OS to know it's been virtualized. You just want to minimize the size of the interface. That's why there's all these hooks for coordinating between an virtualized OS and its hypervisor.
Even if you want a very, very narrow interface, and want to provide a very, very convincing emulation of a system to the hosted OS, letting it know which "stepping" of the "virtual CPU" still seems like a good idea. Saying it doesn't need to know which virtualization layer you're running on is like saying it doesn't need to know what model and stepping CPU you're running on because they all implement the same architecture.
Well, while that's true in 99.44% of the system, individual CPU model/stepping combos have their own tricky bugs that a very small part of the OS usually has to be aware of. Virtual CPUs are no different, and I'd argue are more likely to have bugs since now you have both bugs in the underlying real CPU and bugs in the hypervisor to contend with.
Bugs in silicon are here to stay (even if microcode updates can help on some issues), while bugs in virtualization software will eventually get corrected. So working around those does not sound like a good idea.
And if you really want to have a deep insight on the virtualization layer you're running on, you're better off with some dedicated interface.
If a project calls itself a VM instead of a "hypervisor" (or some other "paravirtualization" term) then that means it's taking responsibility for providing full compatibility with the hardware it claims to be emulating.
So really, bugs in VMs (a-la VMWare, QEmu, Bochs...) shouldn't be the user's responsibility to work around, and workarounds will only prevent the bugs from being reported upstream.
In practice, I'm sure there are corporate customers who really would throw developer resources at workarounds, so yeah, maybe the "solution" is to have a 'announce CPUID' option in the software to allow those who feel they *have to* work around something pull it off in the short term. That flag could be included in .vmdks or the equivalent so anyone taking a workaround into their own hands could deploy it easily.
Good point
They should have their own identifier. Instead of using an existing identifier.
Example "VM CPU x86" or something.
But then that ruins the
But then that ruins the point of emulation. The operating system should never know it's being run inside a virtual machine, ideally.
Perhaps a modified CPUID could be used for debugging? Don't existing virtual machines already support this?
Not entirely true.
You can still have a virtual machine which provides a slightly different environment inside the VM than you'd find on the bare metal, and virtualize a "vanilla" OS just fine. IBM's VM, for instance, has a special instruction which traps to the hypervisor for various services. It's a well-known technique, and provided that it doesn't alter any existing code's ability to run, shouldn't cause any real problems.
Not true at all
It's ok for the OS to know it's been virtualized. You just want to minimize the size of the interface. That's why there's all these hooks for coordinating between an virtualized OS and its hypervisor.
Even if you want a very, very narrow interface, and want to provide a very, very convincing emulation of a system to the hosted OS, letting it know which "stepping" of the "virtual CPU" still seems like a good idea. Saying it doesn't need to know which virtualization layer you're running on is like saying it doesn't need to know what model and stepping CPU you're running on because they all implement the same architecture.
Well, while that's true in 99.44% of the system, individual CPU model/stepping combos have their own tricky bugs that a very small part of the OS usually has to be aware of. Virtual CPUs are no different, and I'd argue are more likely to have bugs since now you have both bugs in the underlying real CPU and bugs in the hypervisor to contend with.
--
Program Intellivision and play Space Patrol!
Bugs in silicon are here to
Bugs in silicon are here to stay (even if microcode updates can help on some issues), while bugs in virtualization software will eventually get corrected. So working around those does not sound like a good idea.
And if you really want to have a deep insight on the virtualization layer you're running on, you're better off with some dedicated interface.
If a project calls itself a
If a project calls itself a VM instead of a "hypervisor" (or some other "paravirtualization" term) then that means it's taking responsibility for providing full compatibility with the hardware it claims to be emulating.
So really, bugs in VMs (a-la VMWare, QEmu, Bochs...) shouldn't be the user's responsibility to work around, and workarounds will only prevent the bugs from being reported upstream.
In practice, I'm sure there are corporate customers who really would throw developer resources at workarounds, so yeah, maybe the "solution" is to have a 'announce CPUID' option in the software to allow those who feel they *have to* work around something pull it off in the short term. That flag could be included in .vmdks or the equivalent so anyone taking a workaround into their own hands could deploy it easily.