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

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

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 vendor 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.

Tim.

> We may have to resort to more vendor specific information within the
> process to handle possible different HW stuff. If above suggestion is
> reasonable, then I think we don't need this wrapper change because we
> can easily extend current vendor speifc inject_exception to support
> both nested case and non-nested case.

-- 
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