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

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

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 & 
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel