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: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, Christoph Egger <Christoph.Egger@xxxxxxx>
Subject: RE: [Xen-devel] [PATCH 07/14] Nested Virtualization: trap
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Thu, 19 Aug 2010 10:44:59 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Delivery-date: Wed, 18 Aug 2010 19:50:06 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1A42CE6F5F474C41B63392A5F80372B22A3E5B97@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acs/RPP8u7Yur6S6RBCXVkCgYPB8MwAAOWjg
Thread-topic: [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 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 
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.

Thx, Eddie
Xen-devel mailing list