From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Re: expose host CPU features to guests Date: Sun, 09 Sep 2007 15:55:07 +0300 Message-ID: <46E3ED2B.6080606@qumranet.com> References: <20070905174530.GA3945@karma.qumranet.com> <1189020371.7206.3.camel@squirrel> <20070907104738.GA14723@mail.shareable.org> <46E3A618.7030505@qumranet.com> <20070909124718.GE24240@mail.shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel , qemu-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org To: Jamie Lokier Return-path: In-Reply-To: <20070909124718.GE24240-tp2ajI7sM85Y6zH9YvfY1x2eb7JE58TQ@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org 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/