From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:37575)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <pl@kamp.de>)
	id 1VijhA-0008G4-BZ
	for qemu-devel@nongnu.org; Tue, 19 Nov 2013 06:42:24 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pl@kamp.de>) id 1Vijh1-00046d-H4
	for qemu-devel@nongnu.org; Tue, 19 Nov 2013 06:42:16 -0500
Received: from mx.ipv6.kamp.de ([2a02:248:0:51::16]:37843 helo=mx01.kamp.de)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <pl@kamp.de>)
	id 1Vijh1-000466-6O
	for qemu-devel@nongnu.org; Tue, 19 Nov 2013 06:42:07 -0500
Message-ID: <528B4E97.7020904@kamp.de>
Date: Tue, 19 Nov 2013 12:42:15 +0100
From: Peter Lieven <pl@kamp.de>
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> <528A701D.8020002@kamp.de>
	<528B4262.9050409@redhat.com> <528B4CF6.4090606@kamp.de>
	<528B4D70.2050403@redhat.com>
In-Reply-To: <528B4D70.2050403@redhat.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PULL 11/13] target-i386: forward CPUID cache
 leaves when -cpu host is used
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, =?ISO-8859-15?Q?Beno=EEt_Canet?= <benoit@irqsave.net>

On 19.11.2013 12:37, Paolo Bonzini wrote:
> Il 19/11/2013 12:35, Peter Lieven ha scritto:
>> next question: is cache leaf forwarding a migration blocker?
> "-cpu host" in general is "interesting" at migration time, so I would
> say no.
It works for for a long time as long as all cpu features that are supported on the source
are also supported on the destination.

As for the cache leaves feature I would go for making it a optional parameter. If we
woudl want to support it, we need to adjust several cpuid indexes to reflect the emulated
cpu topology. Question would be to what extend the cache information would then
make sense. Or with other words if one wants to use cache leaf pass-thru the topology
must match the physical one?

Peter