From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: [Qemu-devel] KVMs default CPU type (was: allow sysenter on 32bit guests running on vmx host) Date: Thu, 25 Jun 2009 10:11:58 +0200 Message-ID: <4A43314E.5050500@amd.com> References: <20090623162140.GB4379@random.random> <20090624172934.GG14121@shareable.org> <20090624211200.GD15263@random.random> <20090624213944.GD14121@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrea Arcangeli , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Jamie Lokier Return-path: Received: from va3ehsobe001.messaging.microsoft.com ([216.32.180.11]:4717 "EHLO VA3EHSOBE001.bigfish.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1759243AbZFYIJe (ORCPT ); Thu, 25 Jun 2009 04:09:34 -0400 In-Reply-To: <20090624213944.GD14121@shareable.org> Sender: kvm-owner@vger.kernel.org List-ID: [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