From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Fwd: [PATCH 0/18] Nested Virtualization: Overview Date: Fri, 16 Apr 2010 18:50:32 +0100 Message-ID: References: <20100416102711.GA31304@whitby.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100416102711.GA31304@whitby.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Tim Deegan , Christoph Egger Cc: "xen-devel@lists.xensource.com" , Qing He List-Id: xen-devel@lists.xenproject.org On 16/04/2010 11:27, "Tim Deegan" wrote: >> Please read the XenNestedHVM.pdf paper, particularly the section "Software >> Architecture". This describes how this is made to be generic and what needs >> to be done to adapt to Intel. > > Your PDFs suggest that even on Intel CPUs, the nested hypervisor should > always see SVM, not VMX. You shouldn't be surprised or offended if that > isn't popular with Intel. :) I don't see any good argument for it either. I.e., I don't think we care about migrating between AMD and Intel hosts with nestedhvm enabled, which I think would be the only argument for it. I know we added support for cross-emulating SYSENTER and SYSCALL, but that's needed for cross-migration of any 64-bit guest running compat-mode apps (i.e., really need to make cross-migration possible at all). I'm sceptical enough of the utility of cross-vendor migration *at all*, let alone supporting in tandem with advanced features also of dubious utility (at least in enterprise space), like nestedhvm. -- Keir