From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJaC6-0001Rf-KN for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:39:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJaC2-0001Ht-LQ for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:39:50 -0400 Received: from [199.232.76.173] (port=47768 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJaC2-0001Hb-Hc for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:39:46 -0400 Received: from mail2.shareable.org ([80.68.89.115]:52371) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MJaC2-0006U5-1r for qemu-devel@nongnu.org; Wed, 24 Jun 2009 17:39:46 -0400 Date: Wed, 24 Jun 2009 22:39:44 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] allow sysenter on 32bit guests running on vmx host Message-ID: <20090624213944.GD14121@shareable.org> References: <20090623162140.GB4379@random.random> <20090624172934.GG14121@shareable.org> <20090624211200.GD15263@random.random> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090624211200.GD15263@random.random> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli Cc: qemu-devel@nongnu.org Andrea Arcangeli wrote: > Hi Jamie, > > thanks for review! > > On Wed, Jun 24, 2009 at 06:29:34PM +0100, Jamie Lokier wrote: > > So your patch should make no difference to Linux guests. Did you > > check Linux behaviour? Does Windows ignore the vendor id? > > Maybe I wasn't clear enough, this patch only makes a difference for > KVM. KVM switches the vendor id to Intel when run on vmx host. It > definitely makes a difference to linux guest, without this patch 32bit > linux run as guest on top of KVM has sep disabled in /proc/cpuinfo and > isn't using sysenter (just like windows, hence the skype crash). I > verified 32bit linux guest has sep enabled with this patch applied > when run on KVM on top of intel. That was not at all clear. What's missing is a comment saying "KVM changes this vendor id to Intel when run on a VMX-capable host". So what happens if you have a guest which worked fine under QEMU, then breaks because it sees a changed vendor id when you run it under KVM? I guess the guest, being Windows, tells you to make a phone call to Microsoft because you changed the CPU, if you're out of luck. 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? > 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? :-) 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. 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. -- Jamie