|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] RE: [Xen-changelog] [xen-unstable] Initial support for H
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年1月15日 15:43
>
>On 15/1/07 6:31 am, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> Or it means a
>> compat-dom0 coupled with 32bit HVM? Or something like to reuse
>> new compat layer for HVM side if translation required?
>
>Both of the above.
>
> -- Keir
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)
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.
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.
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. :-)
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|