From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJyNc-0005mh-Bv for qemu-devel@nongnu.org; Thu, 25 Jun 2009 19:29:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJyNX-0005dx-N5 for qemu-devel@nongnu.org; Thu, 25 Jun 2009 19:29:20 -0400 Received: from [199.232.76.173] (port=40482 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJyNX-0005do-Iu for qemu-devel@nongnu.org; Thu, 25 Jun 2009 19:29:15 -0400 Received: from mx2.redhat.com ([66.187.237.31]:41566) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJyNX-0005HW-4w for qemu-devel@nongnu.org; Thu, 25 Jun 2009 19:29:15 -0400 Date: Fri, 26 Jun 2009 01:27:11 +0200 From: Andrea Arcangeli Subject: Re: [Qemu-devel] allow sysenter on 32bit guests running on vmx host Message-ID: <20090625232711.GC12992@random.random> References: <20090623162140.GB4379@random.random> <200906251839.20253.paul@codesourcery.com> <20090625210249.GB12992@random.random> <200906252312.08945.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906252312.08945.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org On Thu, Jun 25, 2009 at 11:12:08PM +0100, Paul Brook wrote: > I don't buy this. I'd expect a a good proportion of users to care more about > correct operation over absolute performance. A fast VM is no good if it > doesn't actually work. Be sure CPUs with vendor_id intel provides correct operation too :). I fail to see what's wrong in telling the guest it's running on a intel CPU when the physical CPU is intel. We're not emulating a CPU, we're virtualizing it. This is not QEMU we're talking about. > On closer inspection I notice that we use an AMD vendor ID for the "qemu64" > cpu. IMO this is wrong, we should be using our own ID. However this does not > change the underlying problem - KVM absolutely should not be unilaterally > changing the reported vendor ID. Maybe select a different CPU by default, and > probably fail to run if the selected CPU ID is incompatible with the host > hardware features, but not arbitrarily mutate the provided CPUID. KVM users wants performance in their apps anything else is secondary, otherwise they would be fine using qemu, no? What's wrong with qemu besides performance? Besides I think there is breakage in setting the SEP feature on athlon definition for example, I don't have an hardware athlon around to check /proc/cpuinfo though, but I don't think SEP would be enabled there. Let's focus on performance (and facts like SEP being enabled on athlon) without shooting ourself in the foot by breaking all guest OS assumptions with an unknown qemu vendor ID. Or if you really want to argue, in most others thread you pretend qemu should be as close as possible as hardware (no matter if guest breaks), and I know no hardware with your brand new qemu vendor_id, do you? (yeah not even the model name is reflecting hardware very well I know, but that didn't happen to break stuff yet so it can stay as default for now)