From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJygy-0004S8-A0 for qemu-devel@nongnu.org; Thu, 25 Jun 2009 19:49:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJygs-0004QP-VF for qemu-devel@nongnu.org; Thu, 25 Jun 2009 19:49:19 -0400 Received: from [199.232.76.173] (port=49123 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJygs-0004QD-Ha for qemu-devel@nongnu.org; Thu, 25 Jun 2009 19:49:14 -0400 Received: from mx20.gnu.org ([199.232.41.8]:26243) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJygs-00007i-3S for qemu-devel@nongnu.org; Thu, 25 Jun 2009 19:49:14 -0400 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJygq-0001Cj-WA for qemu-devel@nongnu.org; Thu, 25 Jun 2009 19:49:13 -0400 From: Paul Brook Subject: Re: [Qemu-devel] allow sysenter on 32bit guests running on vmx host Date: Fri, 26 Jun 2009 00:49:06 +0100 References: <20090623162140.GB4379@random.random> <200906252312.08945.paul@codesourcery.com> <20090625232711.GC12992@random.random> In-Reply-To: <20090625232711.GC12992@random.random> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906260049.07724.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli Cc: qemu-devel@nongnu.org > KVM users wants performance in their apps anything else is secondary, > otherwise they would be fine using qemu, no? No. According to others in this thread, migration between different hosts is also important, as is isolation from host machine specifics. In fact I'm skeptical how much benefit using an Intel/AMD vendor ID gets you by way of performance. While you may be running code "natively", there's still an awful lot of things that trap back to the hypervisor, so you're liable to get different performance characteristics to a native CPU. > 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) You're missing the point. "-cpu host" or "-cpu p6" (where p6 is lowest-common- denominator) may be a reasonable default for KVM. What's not acceptable (as evidenced by this bug) is taking an arbitrary CPUID and blindly sticking an Intel vendor ID on it. Paul