This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-devel] [PATCH 07/14] Nested Virtualization: trap

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 07/14] Nested Virtualization: trap
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Thu, 19 Aug 2010 21:53:14 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Christoph Egger <Christoph.Egger@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Delivery-date: Thu, 19 Aug 2010 06:59:08 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100819083552.GF20252@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1A42CE6F5F474C41B63392A5F80372B22A3E5B97@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <1A42CE6F5F474C41B63392A5F80372B22A3E5C06@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20100819083552.GF20252@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acs/eYvLloC7V+h1SdmVZEM+mxD8qwAKGgog
Thread-topic: [Xen-devel] [PATCH 07/14] Nested Virtualization: trap
Tim Deegan wrote:
> At 03:44 +0100 on 19 Aug (1282189499), Dong, Eddie wrote:
>>> +int hvm_inject_exception(unsigned int trapnr, int errcode,
>>> unsigned long cr2) +{ +    uint64_t exitcode;
>>> +    bool_t is_intercepted;
>>> +    struct vcpu *v = current;
>>> +    struct nestedhvm *hvm = &VCPU_NESTEDHVM(v);
>>> +
>>> +    if ( !nestedhvm_enabled(v->domain) ) {
>>> +        hvm_funcs.inject_exception(trapnr, errcode, cr2); +       
>>> return 0; +    }
>> If it is not nested, we go from here to vendor specific injection
>> code. If it is nested, I think we'd better to go to another vendoral
>> specific handler too.
> That's exactly what this wrapper does.  It's basically:
>  if ( in L2 and L1 intercepts )
>     force vmexit
>  else
>     inject directly.
> It calls out to arch-specific code to do the intercept check and the
> vmexit.  It could be tidied up a bit and the interfaces could change
> but this looks like about the least amount of sharing there could be
> on this path.  I can't see anything objectionable.

Is there any real data to show the saving LOC here? I see the real code start 
from "exitcode = nestedhvm_exception2exitcode(trapnr);" (half of this function 
code is just for wrapper check.). The real work is ~20LOC. However we added at 
least 2 new wrapper APIs: nestedhvm_exception2exitcode & 

Especially when you look at "nsvm_vmcb_exitcode_native2generic" in patch 10, 
which generates ~70 new LOC and another 70 new LOC in 
"nsvm_vmcb_exitcode_generic2native". If VMX side has to adop this framework, 
then another new 140 LOC has to be generated. (Total 280 new LOC)

If you look back to 5 years ago, in single layer virtualization side, we 
adopted the wrapper function because it is a must to make SVM work. However for 
nested virtualization, at least this wrapper is just a wrapper for wrapping 
with not clear or trivial benefits but clearly sacrificing 
readability/simplicity/flexibility etc.

BTW, from concept point of view, we don't call (virtual) vm exit as exception.

Thx, Eddie
Xen-devel mailing list