From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VimyO-0005Uj-7W for qemu-devel@nongnu.org; Tue, 19 Nov 2013 10:12:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VimyH-0006to-KH for qemu-devel@nongnu.org; Tue, 19 Nov 2013 10:12:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VimyH-0006te-Bj for qemu-devel@nongnu.org; Tue, 19 Nov 2013 10:12:09 -0500 Message-ID: <528B7FB1.8080700@redhat.com> Date: Tue, 19 Nov 2013 16:11:45 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1379694292-1601-1-git-send-email-pbonzini@redhat.com> <1379694292-1601-12-git-send-email-pbonzini@redhat.com> <528A310A.60607@dlhnet.de> <528A3422.1030701@kamp.de> <528A3C4A.4090001@redhat.com> <528B3C86.3030309@kamp.de> <528B41A5.1080504@redhat.com> <528B53A6.3030204@kamp.de> <528B561C.9070200@redhat.com> <528B5A5B.1090705@kamp.de> <528B65E6.7040203@redhat.com> <528B7190.1060009@kamp.de> <528B7262.1010909@redhat.com> <528B7303.3070204@kamp.de> <528B738B.8080805@redhat.com> <528B79CA.7080109@kamp.de> <528B7C40.8050309@redhat.com> <528B7E39.6050905@kamp.de> In-Reply-To: <528B7E39.6050905@kamp.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PULL 11/13] target-i386: forward CPUID cache leaves when -cpu host is used List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Lieven Cc: qemu-devel@nongnu.org, Anthony Liguori , =?UTF-8?B?QmVub8OudCBDYW5ldA==?= Il 19/11/2013 16:05, Peter Lieven ha scritto: >> >>> What about the number of threads in count == 2? >> That's a property of the L2 cache. It's not related to APIC IDs. > okay, but the contents could be wrong if the physical system > has threads while the emulated vserver has not. does this > matter? If you care about passing cache leaves, you probably can be expected to pass a number of threads that matches the host, making the vCPUs a multiple of the number of threads, and pinning the virtual cores to the physical cores. But in general, I'd say that the cache _is_ shared with another thread. It may be that the thread is not part of the VM---that depends on things such as the pinning of vCPUs to physical CPUs. Paolo