From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IUMVi-0005HM-Qw for qemu-devel@nongnu.org; Sun, 09 Sep 2007 09:07:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IUMVh-0005Ef-M7 for qemu-devel@nongnu.org; Sun, 09 Sep 2007 09:07:34 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IUMVh-0005EQ-IF for qemu-devel@nongnu.org; Sun, 09 Sep 2007 09:07:33 -0400 Received: from mail.shareable.org ([81.29.64.88]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IUMVh-0007q0-0h for qemu-devel@nongnu.org; Sun, 09 Sep 2007 09:07:33 -0400 Date: Sun, 9 Sep 2007 14:07:25 +0100 From: Jamie Lokier Subject: Re: [kvm-devel] [Qemu-devel] Re: expose host CPU features to guests Message-ID: <20070909130725.GF24240@mail.shareable.org> 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> <46E3ED2B.6080606@qumranet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46E3ED2B.6080606@qumranet.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: kvm-devel , qemu-devel@nongnu.org Avi Kivity wrote: > 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. I have a feeling you won't ever see it either, but not because it's a missing feature. Instead, I think a very small number of users will spend hours frustrated that some obscure guest doesn't work properly on their obscure x86 hardware, then they will learn that they should not use "-cpuid host" for that guest on that hardware, even though it works fine with other guests, and then their problem will be solved (albeit at a cost), and seen as such an obscure combination that it might never be reported to Qemu developers. In other words, host-os is what _I'd_ implement because I care too much about the poor obscure users and think it's the safe option, but I'm not doing the implementing here ;-) If you are curious what the differences are, do this in a current Linux source tree: egrep -R '(set|clear)_bit\(X86_FEATURE' arch/{i386,x86_64}/kernel -- Jamie