From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IUHaL-0004i5-Hi for qemu-devel@nongnu.org; Sun, 09 Sep 2007 03:52:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IUHaK-0004ht-VC for qemu-devel@nongnu.org; Sun, 09 Sep 2007 03:52:01 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IUHaK-0004hq-SH for qemu-devel@nongnu.org; Sun, 09 Sep 2007 03:52:00 -0400 Received: from il.qumranet.com ([82.166.9.18]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IUHaK-0005WC-8l for qemu-devel@nongnu.org; Sun, 09 Sep 2007 03:52:00 -0400 Message-ID: <46E3A618.7030505@qumranet.com> Date: Sun, 09 Sep 2007 10:51:52 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [kvm-devel] [Qemu-devel] Re: expose host CPU features to guests References: <20070905174530.GA3945@karma.qumranet.com> <1189020371.7206.3.camel@squirrel> <20070907104738.GA14723@mail.shareable.org> In-Reply-To: <20070907104738.GA14723@mail.shareable.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: kvm-devel , qemu-devel@nongnu.org Jamie Lokier wrote: > Anthony Liguori wrote: > >> I like this idea but I have some suggestions about the general approach. >> I think instead of defining another machine type, it would be better to >> just have a command line option like -cpuid that took a comma separate >> string of features with "all" meaning all features that the host has. >> > > I like the idea of a flag to enable specific features, but I think > "host" would be a better name for the features of the host. > > "all" seems more appropriate to enable all the features the emulator > can support, which can include features which the host does not > support itself. > > If it's a comma separated list, it would be good to be able to write > something like this example, which selects all the host features but > then overrides it by disabling the psn feature: > > -cpuid host,-psn > Yes, 'host' and 'all' make more sense the way you describe them from the emulator perspective. > Is it intended that these flags will also control the actual features > which Qemu allows or emulates, or only what cpuid reports to the guest? > > The cpuid features are sufficient (and there's precedent -- some mobile intel processors support pae but don't report it). >> I also think it would be nicer to use cpuid() directly instead of >> attempting to parse /proc/cpuinfo. >> > > Occasionally the features in /proc/cpuinfo differ from what the cpuid > instruction reports. They are CPU bug workarounds (features disabled > intentionally even though cpuid reports them), CPU features which > aren't properly reported (enabled intentionally in cpuinfo), and boot > flag requests (features disabled due to request from the boot command > line). > > I'm inclined to think the feature list in /proc/cpuinfo is more > appropriate, for choosing the best set of host features to make > available to guests. It's unlikely that Qemu itself will duplicate > the logic of known workarounds for specific, obscure, buggy host CPUs. > > There is also /dev/cpu/%d/cpuinfo (for %d = 0, 1, etc.) on some Linux > distros, I think. > Well, the guest will invoke its own workaround logic to disable buggy features, so I see no issue here. -- error compiling committee.c: too many arguments to function