From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MRTwJ-0002iF-9E for qemu-devel@nongnu.org; Thu, 16 Jul 2009 12:36:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MRTwE-0002aa-EZ for qemu-devel@nongnu.org; Thu, 16 Jul 2009 12:36:10 -0400 Received: from [199.232.76.173] (port=39823 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRTwD-0002aE-PW for qemu-devel@nongnu.org; Thu, 16 Jul 2009 12:36:05 -0400 Received: from mail2.shareable.org ([80.68.89.115]:53771) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MRTwD-0001UA-Cu for qemu-devel@nongnu.org; Thu, 16 Jul 2009 12:36:05 -0400 Date: Thu, 16 Jul 2009 17:36:02 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] omit 3DNOW! CPUID bits from qemu64 CPU model Message-ID: <20090716163602.GH16461@shareable.org> References: <1247748571-20326-1-git-send-email-andre.przywara@amd.com> <20090716160128.GF16461@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Andre Przywara , qemu-devel@nongnu.org Alexander Graf wrote: > >safe32 => common between KVM and TCG, 32-bit > >safe64 => common between KVM and TCG, 64-bit > > Yeah. Maybe only "safe" and always assume x86_64? But then comes > Intel ... sigh. Why x86_64? Some of use run KVM on 32-bit host CPUs. They're not antiques yet :-) -- Jamie > >>That would also make it easier to know where to put other fancy > >>features like "SVM" :-) > > > >Can't we use SVM emulation with TCG and KVM both? > > We can use SVM emulation with TCG and KVM on SVM. Yay! Oh, wait, I have VMX instead :-/ > We can't on KVM with VMX and Xen HVM. For KVM it's fine though, > because the feature gets masked out if it's not supported. Ok. I'm a bit surprised SVM isn't just easy to emulate on VMX, if it's done by emulating instructions and state transitions. Is SVM particularly good for nesting so that you don't need much emulation code in KVM's in-kernel minimal emulator? I'm biased as I was hoping to run nested KVMs on my VMX 32-bit Intel :-D > Still, SVM isn't migratable on KVM atm, so let's better disable it for > "safe". I agree, non-migratable things should be disabled for "safe". Is it because there's hidden state, or simply unimplemented save/load code? -- Jamie