Avi Kivity wrote:
Well, the guest will invoke its own workaround logic to disable buggy
features, so I see no issue here.
The guest can only do this if it has exactly the correct id
information for the host processor (e.g. "This is an Intel Pentium Pro
model XXX"), not just the list of safe to use CPU features.
This isn't possible in a virtualisation cluster of many different CPUs
where the point is to advertise the common set of cpuid features, and
for the guest images to be able to migrate between different CPUs in
the cluster.
But sometimes it's good to run a simple guest (e.g. someone's pet OS
project, or anything written for Intel only which was more common in
the past) which doesn't have all the detailed obscure workarounds of
something like Linux, but still be able to take advantage of the
workarounds and obscure knowledge in the host.
The alternative is Qemu itself may end up having to have some of these
obscure workarounds :/
For example, the sysenter instruction is advertised on early Pentium
Pros, but it doesn't work. Linux removes it from the features in
/proc/cpuinfo, and doesn't use it. But some guests simply don't get
that obscure, and use it if cpuid advertises it. Of course, they
don't work on a _real_ early Pentium Pro. But it would be nice if
they did work without anything special when run in Qemu on such a
host. That's an old chip which I happen to know about, but I'm sure
there are more modern similar issues.
Perhaps there could be two options then: "-cpuid host-os", and "-cpuid
host-cpuid". I would suggest making "host" an alias for "host-os",
but I wouldn't object if it were an alias for "host-cpuid" or didn't
exist at all, so you had to choose one.