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:16:38 +0000
Delivery-date: Mon, 15 Jan 2007 00:16:24 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F9E109A@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/xnx7jpkDRTyKsEVGkKWVRwHYc7AQAAKt9UUAAFJcwAAA2gyt
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:07 am, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> So is this still on development for HVM? I didn't find where
> _DOMF_COMPAT is set for 32bit HVM guest, and then compat
> logic under is_hvm_vcpu may not make effect yet. (Correct me if
> I'm wrong)

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.

> Other incompleteness is like, XLAT_cpu_user_regs is invoked
> after hvm_store_cpu_guest_regs in arch_get_info_guest, while
> arch_set_info_guest invokes hvm_load_cpu_guest_regs directly,
> etc.

Yes, that's an incompleteness. Stuff is getting implemented on demand. Noone
uses arch_set_info_guest() on an HVM guest, but xc_ptrace() does use
arch_get_info_guest() so I guess Jan fixed that one up.

> Also, one question is whether COMPAT mode requires all guests
> to be in compatible, or can be mixed like 64bit dom0 + 32bit domU.
> Still take arch_get_info_guest for example:
>    Vcpu_guest_context is translated if target domain is compat
> mode, while there's no check for current domain's mode. Then
> compat context is copied back to dom0 even when dom0 is a 64bit
> guest.

Currently we require all guests to be in the same mode. However, there are
tools changes in progress to allow mixed-mode guests. Checking COMPAT of
caller vs. target is indeed a bit confusing. We'll audit the domctl
interfaces and make up our mind how that should work when we apply the tools
changes for mixed-mode guests.

> Are things like above deliberately made to depend on dom0 aware
> of target guest context layout, or something still immature? I just want
> to get a clear picture what impact this new compatible mode may bring
> to the whole environment. :-)

dom0 must be aware of target guest context. It builds the page tables for
example. :-) So it is acceptable for him to have to use different domctl()
commands to initialise 32- vs 64-bit pv guests (although we obviously want
to avoid bloating the interface with compat crap as far as possible).

 -- Keir



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