From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Deegan Subject: Re: [PATCH 0/14] Nested Virtualization: Overview Date: Tue, 17 Aug 2010 13:30:03 +0100 Message-ID: <20100817123003.GC20252@whitby.uk.xensource.com> References: <201008171233.30154.Christoph.Egger@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Christoph Egger , "xen-devel@lists.xensource.com" , "Dong, Eddie" List-Id: xen-devel@lists.xenproject.org At 11:41 +0100 on 17 Aug (1282045318), Keir Fraser wrote: > On 17/08/2010 11:33, "Christoph Egger" wrote: > > Tim and Keir made clear they don't want to have two implementations after > > I submitted my patch series the *first* time. > > I think maybe this is an argument over two different things. To be clear we > want to support VMX-on-VMX and SVM-on-SVM. I assume this is what Christoph > means by HVM-on-HVM: any-like-on-like. In which case there is no > disagreement here. > > Now, separately there is a debate to be had on how much code can be shared > in HVM-on-HVM, given the big differences between VMX and SVM. I would guess > that there will be at least things in the area of nested shadow and nested > HAP that can be shared, for example. Probably there is other stuff too. The > question is to what degree do we pursue that now rather than get divergent > stuff in tree and then go after it later. My mind isn't totally made up on > that; I don't know about Tim's. The general tone of Christoph's latest patchset seems about right to me: the concept of a VCPU being in nested HVM mode or not, the control interface, and the bulk of the interrupt/exception injection logic seem like they should be common from day one, unless there's a particular reason not to. The details of exactly how the nested VMC[BS] is accessed and updated are of course arch-specific. The two HAP-on-HAP designs are quite different but since all the EPT code is already separate from the other p2m code that's OK. Shadow-on-shadow and shadow-on-HAP ought to just work[tm] without any extra moving parts. I've no strong feelings about the details of the interface between the common and the arch-specific code, but it seems like with a bit of flexibility on both sides it could be made suitable for everyone. Cheers, Tim. -- Tim Deegan Principal Software Engineer, XenServer Engineering Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)