From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJk1h-00079d-54 for qemu-devel@nongnu.org; Thu, 25 Jun 2009 04:09:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJk1c-00072u-Ky for qemu-devel@nongnu.org; Thu, 25 Jun 2009 04:09:44 -0400 Received: from [199.232.76.173] (port=38518 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJk1c-00072U-7m for qemu-devel@nongnu.org; Thu, 25 Jun 2009 04:09:40 -0400 Received: from va3ehsobe001.messaging.microsoft.com ([216.32.180.11]:4723 helo=VA3EHSOBE001.bigfish.com) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.60) (envelope-from ) id 1MJk1b-0000g4-T5 for qemu-devel@nongnu.org; Thu, 25 Jun 2009 04:09:40 -0400 Message-ID: <4A43314E.5050500@amd.com> Date: Thu, 25 Jun 2009 10:11:58 +0200 From: Andre Przywara MIME-Version: 1.0 Subject: [Qemu-devel] KVMs default CPU type (was: allow sysenter on 32bit guests running on vmx host) References: <20090623162140.GB4379@random.random> <20090624172934.GG14121@shareable.org> <20090624211200.GD15263@random.random> <20090624213944.GD14121@shareable.org> In-Reply-To: <20090624213944.GD14121@shareable.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Andrea Arcangeli , qemu-devel@nongnu.org, kvm@vger.kernel.org [CCing kvm@vger] Jamie Lokier wrote: > Andrea Arcangeli wrote: >> Hi Jamie, >... > > It looks like it could be a KVM mis-feature. > > Is the changing vendor id actually useful for anything, without > updating the family/model/stepping at the same time? E.g. does it > make some guest things work, even though other parts of the cpuid > don't reflect the host? (sysenter/sysexit in 32bit compat mode, see below) > >> Another approach is to switch model to 3 along with vendor_id in KVM >> but because qemu is already using 6/3/3 when emulating a 32bit x86 >> hardware, I don't think this is simpler and more consistent. > > No, I'm happy with 6/3/3. Like that part of the patch :-) > > Although... there aren't any 64-bit Pentium Pros, so maybe 6/3/3 is a > bit... small? :-) There aren't any K7 Athlons with 64bit, either ;-) I think this whole family 6 thing comes actually from QEMU and it's emulation capabilities and makes no sense in KVM. I think we should go away from using qemu64 as a default for KVM. In my opinion we should target -cpu host as KVM's default, while in parallel create a -cpu migrate type (still fiddling with the CPUID details of that), which takes over the qemu64 role of being some kind of least common denominator. This should be a family 15 CPU (AMD K8 or Intel P4) with a constant vendor ID (in my experiments Intel showed less problems with guests). Since 64bit Windows has a whitelist of known vendor IDs (AMD, Intel on XP, additionally Via on Win7) we cannot use a bogus vendor, although this should impose the least problems. > Now I'm just wondering why the vendor id needs to change dynamically, > if the other cpuid fields aren't changed. If that's useful, then at > least a comment around the qemu64 CPU type to say that happens would > be good. If that's not really a useful feature, then better not to do > it. The dynamic vendor change was introduced to avoid compatibility problems with 32-on-64 compat mode, wherein AMD does not support sysenter (although it does in legacy mode) and Intel does not support syscall (although it does in 64bit mode). See the comment around line 1500 in target-i386/helper.c (or search for vendor_override in current git). Linux's decision whether to use syscall or sysenter depends on the vendor string, so it uses syscall on AMD even when sysenter is advertised. With the sysenter/syscall emulation patches I sent lately and the -cpu host type I think this dynamic vendor ID kludge can go away, since it creates problem with cross-vendor migration (where the vendor ID changes during the guest's runtime) > Maybe it's not useful any more, as "-cpu host" can be used instead (a > recent patch). That had better not break Skype :-) > > For Windows guests, which are sensitive to CPU changes, I prefer not > to change CPU type dynamically without the user knowing. Even with > "-cpu host", I hope (eventually) the chosen CPU type will be stored > when saving/migrating and loaded exactly the same on other hosts, when > it's technically possible. You do not want to use -cpu host if you plan to migrate, another safer CPU type should be used then (the aforementioned -cpu migrate). Although preserving the boot CPU's vendor/family/model/stepping is something that one can think about... Regards, Andre. -- Andre Przywara AMD-OSRC (Dresden) Tel: x29712