[Xen-ia64-devel] RE: vcpu context merge

["Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx>]

I'm not yet convinced of the wisdom of merging these data
structures, but am willing to proceed with the design
discussion.

Comments:

1) Can the shared page be mapped at a fixed or guest-requested
   virtual address for non-VTI guests?   Xen needs to guarantee
   that a PV guest cannot get TLB misses for this page as accessing
   the virtual control registers has vpsr.ic off.  Ideally
   the page should be pinned (by Xen) in a TR as it will be one of
   the most frequently accessed data pages on a PV system.
2) Do we have a solution where vpsr.i and vpsr.ic can be
   atomically modified (e.g. not a bit in a larger vpsr)?
   This is critical for PV performance.  Perhaps we can
   use "shadows" for the vpsr bits that are synchronized
   on entry to Xen?

Dan

> -----Original Message-----
> From: Dong, Eddie [mailto:eddie.dong@xxxxxxxxx] 
> Sent: Wednesday, May 18, 2005 1:30 AM
> To: Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: vcpu context merge
> 
> Dan:
>       For the VCPU context merge, basically the context needs 
> to be shared to XENO OS should be put in 
> vcpu_info_t.arch_vcpu_info_t otherwise we can keep it in 
> exec_domain.arch_exec_domain. From the structure of 
> arch_vcpu_info_t, it includes following parts:
>       1:  parts of guest CR registers.
>       2:  Bank registers (need NAT bits in future)
>       3:  RR/KR/PKR
>       4:  guest TLB
>       5:  time related variables.
>       6: lsapic insvc[]
>       7: Some paravirtualization specific variables.
> 
>       When thinking to merge arch_vmx_struct with 
> arch_vcpu_info_t, #3 is same for both, #4 is different now 
> but we can put both togther now and wait next level of merge. 
> same for #5 & #6.  #7 is XENO only so no merge issue. The key 
> issue is #1 & #2 that is called vpd (virtual processor 
> descriptor) in VTI. VPD include guest CR, vpsr, vpr, bank 
> registers, NAT bits and other regsiters. It needs to be 32K 
> aligned requested by VTI architecture so we use a pointer in 
> arch_exec_domain.arch_vmx_struct. I know it is a little bit 
> difficult for you to access VCR through pointer in XENOLinux. 
> If we can adopt the pointer of vpd in arch_vcpu_info_t, we 
> can put machine address of vpd there to let XENOLinux remap 
> it. Another va point in arch_exec_domain can still exist for 
> HV to access.
>       Any suggestions?
> Eddie
> 

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