From mboxrd@z Thu Jan  1 00:00:00 1970
From: Joerg Roedel <joerg.roedel@amd.com>
Subject: Re: List of unaccessible x86 states
Date: Mon, 26 Oct 2009 12:10:36 +0100
Message-ID: <20091026111036.GJ5326@amd.com>
References: <9D81B6EA-7161-4682-8685-79928C0AC2B3@suse.de>
 <4AE41F2F.2050700@redhat.com>
 <20091026091731.GF5326@amd.com>
 <4AE56A08.5090306@redhat.com>
 <20091026093020.GG5326@amd.com>
 <4AE56E62.2050509@redhat.com>
 <20091026095649.GH5326@amd.com>
 <4AE57555.7000602@redhat.com>
 <20091026104527.GI5326@amd.com>
 <4AE5805F.6020705@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Alexander Graf <agraf@suse.de>, Jan Kiszka <jan.kiszka@web.de>,
	kvm-devel list <kvm@vger.kernel.org>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Gleb Natapov <gleb@redhat.com>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from tx2ehsobe001.messaging.microsoft.com ([65.55.88.11]:30531 "EHLO
	TX2EHSOBE001.bigfish.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1755544AbZJZLKq (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 26 Oct 2009 07:10:46 -0400
Content-Disposition: inline
In-Reply-To: <4AE5805F.6020705@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Mon, Oct 26, 2009 at 12:56:31PM +0200, Avi Kivity wrote:
> On 10/26/2009 12:45 PM, Joerg Roedel wrote:


> >* nested intercepts
> 
> These are part of the guest vmcb.  The host nested intercepts can be
> recalculated, no?
> 
> >* for nested nested paging: guest nested cr3 value
> 
> Part of the guest vmcb.

This will work is most cases. But its not architecturally sane because
real hardware caches this information in the cpu. So software is free to
modify the vmcb without impacting the in-cpu state until the next
#vmexit. I don't know any software which relies on that so it may be not
an issue.
 
> >Off-topic question: Will the new migration protocol include some kind
> >                handshake to find out if migration is possible at all?
> >
> 
> It's assumed that migration always works for a newer qemu version,
> and that the management tools don't attempt backward migration.

I think such a handshake would make sense to just prevent that a nested
svm hypervisor is migrated to an intel machine or vice versa (just an
example, there are more like sse*, nested nested paging, ...).

	Joerg