|   | 
      | 
  
  
      | 
      | 
  
 
     | 
    | 
  
  
     | 
    | 
  
  
    |   | 
      | 
  
  
    | 
         
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
 
 |   
 
 | 
    | 
  
  
    |   | 
    |