Jamie Lokier wrote: > 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. >
Well, for a cluster the management software will coordinate all cpuid features, perhaps taking into account features removed by the host kernel. "-cpu host" is for the gentoo user who wants to enable all the nice cpu flags. > 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. > Exactly. > 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. > Let's start with '-cpu host' as 'cpu host-cpuid' and implement '-cpu host-os' on the first bug report? I have a feeling we won't ever see it. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
