[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> +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 ( nestedhvm_vmentry_emulate(v) ) {
> +        hvm_funcs.inject_exception(trapnr, errcode, cr2);
> +        return 0;
> +    }
> +
> +    if ( !nestedhvm_vcpu_in_guestmode(v) ) {
> +        hvm_funcs.inject_exception(trapnr, errcode, cr2);
> +        return 0;
> +    }
> +
> +    exitcode = nestedhvm_exception2exitcode(trapnr);
> +    hvm->nh_hostflags.fields.forcevmexit = 1;
> +    hvm->nh_forcevmexit.exitcode = exitcode;
> +    is_intercepted = hvm_nestedhvm_vm_intercepted_by_guest(v, exitcode);
> +    hvm->nh_hostflags.fields.forcevmexit = 0;
> +
> +    if ( is_intercepted )
> +    {
> +        enum nestedhvm_vmexits nsret;
> +
> +        hvm->nh_forcevmexit.exitcode = exitcode;
> +        hvm->nh_forcevmexit.exitinfo1 = errcode;
> +        hvm->nh_forcevmexit.exitinfo2 = cr2;
> +
> +        hvm->nh_hostflags.fields.forcevmexit = 1;
> +        nsret = nestedhvm_vcpu_vmexit(v, guest_cpu_user_regs(), 0 /* dummy 
> */);
> +        hvm->nh_hostflags.fields.forcevmexit = 0;
> +
> +        switch (nsret) {
> +        case NESTEDHVM_VMEXIT_DONE:
> +        case NESTEDHVM_VMEXIT_ERROR: /* L1 guest will crash L2 guest */
> +            return 1;
> +        case NESTEDHVM_VMEXIT_HOST:
> +        case NESTEDHVM_VMEXIT_CONTINUE:
> +        case NESTEDHVM_VMEXIT_FATALERROR:
> +        default:
> +            gdprintk(XENLOG_ERR, "unexpected nestedhvm error %i\n", nsret);
> +            return -1;

This new [-1,0,1] return value is ignored by almost all callers.  Would
it be possible to get rid of the special case for #PF, and go back to
returning void?

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.