From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKH34-0001C4-Kd for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:57:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKH30-00019v-Ly for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:57:38 -0500 Received: from [199.232.76.173] (port=41465 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKH30-00019h-Gt for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:57:34 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:53564) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKH30-0005Ck-34 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 14:57:34 -0500 Received: by yxe26 with SMTP id 26so3272399yxe.4 for ; Mon, 14 Dec 2009 11:57:33 -0800 (PST) Message-ID: <4B2698A9.9090107@codemonkey.ws> Date: Mon, 14 Dec 2009 13:57:29 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm References: <20091214193541.GA6150@redhat.com> <4B269596.1050103@codemonkey.ws> <20091214194432.GC6150@redhat.com> In-Reply-To: <20091214194432.GC6150@redhat.com> 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: "Michael S. Tsirkin" Cc: qemu-devel@nongnu.org, gleb@redhat.com, avi@redhat.com Michael S. Tsirkin wrote: > On Mon, Dec 14, 2009 at 01:44:22PM -0600, Anthony Liguori wrote: > >> Michael S. Tsirkin wrote: >> >>> Hi! >>> I have a linux guest where init crashes during boot with invalid opcode error >>> with kernel 2.6.31, but works fine with kernel 2.6.32. >>> It also works fine even with 2.6.31 with qemu-kvm. >>> >>> With Gleb's help, we figured out that the opcode in question is syscall, which >>> is unsupported by hardware on kvm with intel hosts, and is emulated in software >>> with intel hosts in 2.6.32 and up. AMD hosts support this natively. >>> >>> The root cause: by default qemu with kvm enabled reports the following CPU ID: >>> mst@robin:~$ less /proc/cpuinfo >>> processor : 0 >>> vendor_id : AuthenticAMD >>> cpu family : 6 >>> model : 2 >>> model name : QEMU Virtual CPU version 0.11.50 >>> stepping : 3 >>> cpu MHz : 2493.679 >>> cache size : 512 KB >>> fdiv_bug : no >>> hlt_bug : no >>> f00f_bug : no >>> coma_bug : no >>> fpu : yes >>> fpu_exception : yes >>> cpuid level : 4 >>> wp : yes >>> flags : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat >>> pse36 clflush mmx fxsr sse sse2 syscall lm up pni >>> bogomips : 4987.35 >>> clflush size : 64 >>> power management: >>> >>> Problem is, guest sees syscall+AMD vendor and concludes that it is ok to use >>> syscall opcode, which results in a crash (or at least, extra VMExits). >>> I understand from Avi that qemu-kvm solves this problem by reporting >>> the actual CPU vendor from host, to guest. >>> >>> >> The bit that's ugly about that is that we do not save/restore >> cpuid.vendor_id so that would break live migration. >> >> Regards, >> >> Anthony Liguori >> > > This is a feature. It would be very wrong to save/restore cpuid IMO. > It must be part of machine config. > You can already do -cpu qemu64,vendor_id=AuthenticAMD or ,vendor_id=GenuineIntel. If you don't specify anything explicitly, we use AuthenticAMD as a default. Detecting the host by default is problematic because then the same invocation on a different host would change the visible vendor_id. I thought KVM emulates the syscall instruction? I swear I've seen patches for that. Regards, Anthony Liguori