Re: [Xen-devel] [PATCH 0/14] Nested Virtualization: Overview

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

At 11:41 +0100 on 17 Aug (1282045318), Keir Fraser wrote:
> On 17/08/2010 11:33, "Christoph Egger" <Christoph.Egger@xxxxxxx> 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 <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel