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 05/15] Nested Virtualization: core

To: "Dong, Eddie" <eddie.dong@xxxxxxxxx>, Christoph Egger <Christoph.Egger@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH 05/15] Nested Virtualization: core
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Wed, 18 Aug 2010 09:36:58 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 18 Aug 2010 01:37:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1A42CE6F5F474C41B63392A5F80372B229188BD4@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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acs+q9NqHtrjzuT0TVmMdbLolm6bdgAAF2UgAAEVDP8=
Thread-topic: [Xen-devel] [PATCH 05/15] Nested Virtualization: core
User-agent: Microsoft-Entourage/
On 18/08/2010 09:27, "Dong, Eddie" <eddie.dong@xxxxxxxxx> wrote:

>> +enum nestedhvm_vmexits
>> +nestedhvm_vcpu_vmexit(struct vcpu *v, struct cpu_user_regs *regs,
>> +   uint64_t exitcode)
>> +{
> I doubt about the necessary of this kind of wrapper.
> In single layer virtualization, SVM and VMX have its own handler for each VM
> exit. Only when certain common function is invoked, the control goes from
> SVM/VMX to common one, because they have quit many differences and the savings
> by wrapping that function is really small, however we pay with additional
> complexity in both SVM and VMX side as well as readability and performance.
> Further more, it may limit the flexibility to implement something new for both
> side.
> Back to the nested virtualization. I am not fully convinced we need a common
> handler for the VM_entry/exit, at least not for now. It is basically same
> situation with above single layer virtualization. Rather we prefer to jump
> from SVM/VMX to common code when certain common service is requested.
> Will that be easier?

I'm sure there ahs to be conversion-and-demux anyway in SVM-VMX-specific
code. At which point you may as well break out to individual common handler
functions just where that makes sense, as you say. Also I agree this model
fits better with what we do in the non-nested case.

 -- Keir

Xen-devel mailing list