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] RE: [Xen-changelog] [xen-unstable] Initial support for H

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RE: [Xen-changelog] [xen-unstable] Initial support for HVM compat guests
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Mon, 15 Jan 2007 08:38:52 +0000
Delivery-date: Mon, 15 Jan 2007 00:38:39 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F9E109B@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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AccxDEI/xnx7jpkDRTyKsEVGkKWVRwHYc7AQAAKt9UUAAFJcwAAA2gytAAAgxHAAAKYEUw==
Thread-topic: [Xen-devel] RE: [Xen-changelog] [xen-unstable] Initial support for HVM compat guests
User-agent: Microsoft-Entourage/11.3.2.061213
On 15/1/07 8:31 am, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

>> An HVM guest does not use DOMF_COMPAT. You can deduce its
>> execution mode
>> from CS attribute bytes. And of course it can switch execution mode
>> back and
>> forth as it runs, and on different VCPUs, etc.
> 
> So what's the proposed way to reuse compat code for HVM guest?
> Extend IS_COMPAT() to cover HVM domain even when
> DOMF_COMPAT is not set, or invoke compatible layer directly when
> required. In any case, I just didn't see why IS_COMPAT() branch is
> placed under is_hvm_vcpu for now. :-)

Hmmm there is underlying code shared by both compat and native hypercall
layer that will check IS_COMPAT. So jumping at the compat layer is
insufficient (even though that is precisely what the hvm hypercall wrapper
does).

Basically this work isn't complete yet. Probably what will happen is that
the IS_COMPAT() test will be made per-vcpu rather than per-domain and we
will set the per-vcpu flag correctly for an hvm guest at least whenever it
vmexits for a hypercall. Or we will make IS_COMPAT() look at shadow-mode
guest_levels if it is invoked on an HVM vcpu.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel