From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: KVM Processor cache size Date: Mon, 02 Aug 2010 17:25:00 -0500 Message-ID: <4C5745BC.30908@codemonkey.ws> References: <4C56BF6F.9040402@amd.com> <4C56C353.7020607@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andre Przywara , Ricardo Martins , "kvm@vger.kernel.org" To: Avi Kivity Return-path: Received: from mail-iw0-f174.google.com ([209.85.214.174]:41155 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751694Ab0HBWZD (ORCPT ); Mon, 2 Aug 2010 18:25:03 -0400 Received: by iwn7 with SMTP id 7so4469519iwn.19 for ; Mon, 02 Aug 2010 15:25:03 -0700 (PDT) In-Reply-To: <4C56C353.7020607@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 08/02/2010 08:08 AM, Avi Kivity wrote: > On 08/02/2010 03:51 PM, Andre Przywara wrote: >> Ricardo Martins wrote: >>> Hi guys, >>> >>> I'm having a problem with kvm, my physical machine have 2 processor >>> Xeon E5520, with 8 mb cache size, when i run "cat /proc/cpuinfo" the >>> linux shows 16 processors equal. >>> >>> processor : 15 >>> vendor_id : GenuineIntel >>> cpu family : 6 >>> model : 26 >>> model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz >>> stepping : 5 >>> cpu MHz : 1596.000 >>> cache size : 8192 KB >> > .... >>> The problem is that when I run the same command on the virtual >>> machine, Linux shows the processors with only 32 kb, I believe that >>> anything is wrong. >>> >>> processor : 0 >>> vendor_id : GenuineIntel >>> cpu family : 6 >>> model : 6 >>> model name : QEMU Virtual CPU version 0.9.1 >>> stepping : 3 >>> cpu MHz : 2266.575 >>> cache size : 32 KB >> > .... >>> On virtual Machine: >>> linea:/# x86info >>> x86info v1.21. Dave Jones 2001-2007 >>> >>> >>> Found 1 CPU, but found 16d CPUs in MPTable. >>> -------------------------------------------------------------------------- >>> >>> Family: 6 Model: 6 Stepping: 3 Type: 0 Brand: 0 >>> CPU Model: Celeron / Mobile Pentium II Original OEM >>> Feature flags: >>> fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 >>> clflsh mmx fxsr sse sse2 >>> Extended feature flags: >>> sse3 [31] >>> [0] [2] [3] [4] [5] [6] [7] [8] [9] SYSCALL [13] [15] [16] xd [23] >>> [24] em64t >>> Cache info >>> L1 Instruction cache: 32KB, 8-way associative. 64 byte line size. >>> L1 Data cache: 32KB, 8-way associative. 64 byte line size. >>> L2 unified cache: 2MB, sectored, 8-way associative. 64 byte line size. >>> TLB info >> >> KVM (or better: the QEMU part) injects a bogus CPU model (compare >> family/model/name), which is the same on all host CPUs. This helps >> with migration, because the CPU does not change. >> The cache size is also the same, as it is part of the "cpuid" command >> output. >> You can use other CPU models (like kvm64) for better base models, but >> the cache size will likely not match your host processor's one. >> For that purpose exists the "host" CPU model, which will (to some >> degree) simply push your host CPU model to the guest. For now this >> only affects the family/model/stepping/name values and the feature >> flags. >> I sent a patch to include the cache size when using -cpu host, but >> this has been n'acked because the benefit is not clear. > > Anthony, why was this NACKed? First, there are programs which query > the cache size. That's why it's exposed! Second, -cpu host is for > exposing as many host cpu features as we can, not just those we have > an immediate use for. It's like 'cp -a' dropping attributes the > author didn't care about. That's exactly what the code does today BTW. The kernel module filters cpuid flags, qemu filters additional flags, and we don't pass everything through anyway. -cpu host is a mess and needs some love. It's impossible to use correctly today in a production environment if you care about reliably generating the same guest visible interface. Regards, Anthony Liguori