[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] RE: [Xen-changelog] [xen-unstable] Initial support for HVM compat guests

  • To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Mon, 15 Jan 2007 16:31:50 +0800
  • Delivery-date: Mon, 15 Jan 2007 00:31:43 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AccxDEI/xnx7jpkDRTyKsEVGkKWVRwHYc7AQAAKt9UUAAFJcwAAA2gytAAAgxHA=
  • Thread-topic: [Xen-devel] RE: [Xen-changelog] [xen-unstable] Initial support for HVM compat guests

>-----Original Message-----
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年1月15日 16:17
>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.

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. :-)

Thanks for you kind answer on other questions.

- Kevin

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.