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 04/16] vmx: nest: nested control structure

To: Christoph Egger <Christoph.Egger@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH 04/16] vmx: nest: nested control structure
From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
Date: Wed, 15 Sep 2010 21:46:24 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, "He, Qing" <qing.he@xxxxxxxxx>
Delivery-date: Wed, 15 Sep 2010 06:51:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <201009151531.25129.Christoph.Egger@xxxxxxx>
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: <1283959344-3837-1-git-send-email-qing.he@xxxxxxxxx> <1A42CE6F5F474C41B63392A5F80372B22A8C237B@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <201009151517.43855.Christoph.Egger@xxxxxxx> <201009151531.25129.Christoph.Egger@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: ActU2sdtywJI1cFzTcqNJ/OjcbKNqgAATayA
Thread-topic: [Xen-devel] [PATCH 04/16] vmx: nest: nested control structure
>>>>>  #ifdef __x86_64__
>>>>>      struct vmx_msr_state msr_state;
>>>>>      unsigned long        shadow_gs;
>>>> I think, the structure should be allocated in the
>>>> nestedhvm_vcpu_initialise() function hook and assigned to the
>>>> nh_arch pointer in struct nestedhvm.
>>> Well, the structure itself is pretty small, so dynamic allocation is
>>> really not a good idea.
> It's not a question of size. The point is that it is opaque to
> non-vmx code. 

I think it is anyway recycling again, that is not necessary.
Outside of VMX should not access those VMX specific code in theory. If it needs 
some parameters, vcpu can stand for all of them.

Thx, Eddie
Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>