From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=56300 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OsxOh-0006Gq-Bm
	for qemu-devel@nongnu.org; Tue, 07 Sep 2010 08:35:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OsxOf-00052U-Tb
	for qemu-devel@nongnu.org; Tue, 07 Sep 2010 08:35:35 -0400
Received: from mx1.redhat.com ([209.132.183.28]:33064)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OsxOf-00052D-NO
	for qemu-devel@nongnu.org; Tue, 07 Sep 2010 08:35:33 -0400
Message-ID: <4C86318F.5050101@redhat.com>
Date: Tue, 07 Sep 2010 15:35:27 +0300
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 1/3] qemu-kvm: Invert svm-flag setting logic
References: <1283858843-21330-1-git-send-email-joerg.roedel@amd.com>
	<1283858843-21330-2-git-send-email-joerg.roedel@amd.com>
	<D61749EF-AEDB-4017-AF00-BDE87D6C76C2@suse.de>
	<20100907123016.GA2108@redhat.com>
	<7BED2EED-8D8B-4D42-9208-D3D04C23C77D@suse.de>
In-Reply-To: <7BED2EED-8D8B-4D42-9208-D3D04C23C77D@suse.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/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: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Alexander Graf <agraf@suse.de>
Cc: Joerg Roedel <joerg.roedel@amd.com>, Marcelo Tosatti <mtosatti@redhat.com>, qemu-devel@nongnu.org, kvm@vger.kernel.org

  On 09/07/2010 03:33 PM, Alexander Graf wrote:
>
>> I agree that its much nicer for mgmt tools if svm/vmx CPU flags can just be
>> toggled in the normal manner. Might we also want to have a enable/disable
>> nesting flag, so we can mirror the way real hardware lets you disable virt
>> in the BIOS even when the CPU(s) have the vmx/svm flags set ?
> I don't see how that's useful. We don't model anything like this in the kvm kernel module, so whatever we expose in user space would not be useful for detection testing. Also I'm fairly sure you either want nesting or you don't :). And if you want nesting, you probably want -cpu host too, since you lose migration anyways.

Why do you lost migration?

-- 
error compiling committee.c: too many arguments to function