From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJyzG-0001Bj-Lh for qemu-devel@nongnu.org; Thu, 25 Jun 2009 20:08:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJyzC-000183-UX for qemu-devel@nongnu.org; Thu, 25 Jun 2009 20:08:14 -0400 Received: from [199.232.76.173] (port=54626 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJyzC-00017v-M9 for qemu-devel@nongnu.org; Thu, 25 Jun 2009 20:08:10 -0400 Received: from mx2.redhat.com ([66.187.237.31]:46825) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJyzC-0008Hy-4Q for qemu-devel@nongnu.org; Thu, 25 Jun 2009 20:08:10 -0400 Date: Fri, 26 Jun 2009 02:06:07 +0200 From: Andrea Arcangeli Subject: Re: [Qemu-devel] allow sysenter on 32bit guests running on vmx host Message-ID: <20090626000607.GD12992@random.random> References: <20090623162140.GB4379@random.random> <200906252312.08945.paul@codesourcery.com> <20090625232711.GC12992@random.random> <200906260049.07724.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200906260049.07724.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 Fri, Jun 26, 2009 at 12:49:06AM +0100, Paul Brook wrote: > No. According to others in this thread, migration between different hosts is > also important, as is isolation from host machine specifics. Which is exactly why I'm not patching to -cpu host as it can have other implications. > 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. You didn't answer: what is the hardware in the marketplace with vendor_id=unknown_to_guest_os_qemu? which hardware do you intend to emulate? Not existent hardware? Or just want to create gratuitous pain to guest OS implementations for the sake of intel/amd not giving guest OS enough performance? Besides when int 0x80 is run instead of sysenter by guest OS I'm quite sure there is slowdown in KVM as sysenter will better run natively without exists, or we definitely must disable it for good unconditionally. > 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. We don't take arbitrary cpuid, we take 6/3/3 which is lowest common denominator that we know is not troublesome (6/2/3 is troublesome on intel). Does troublesome pain segfault adjectives are enough to warrant the change from 6/2/3 to 6/3/3? If 6/3/3 wasn't a good enough common denominator for both amd and intel vendor_ID, we'd be proposing a different change indeed. There's probably some screwup to fix in kvm -cpu different_vendor_id_than_host, plus there's likely some screwup in qemu that sets SEP on -cpu athlon (how can it be?), but this patch has only the scope of gettig rid of a troublesome 6/2/3 unlucky combination. If I would patch more than one problem at once you'd be telling me that I'm doing too many things in the same patch and I need to split...