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. Then, the common cpuid features must be found by combining the /proc/cpuinfo from each node in the cluster. But I guess that's separate from the part of Qemu we are discussing; it would be done by another program, preparing the -cpuid argument. 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. -- Jamie