[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
>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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |