WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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