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

["Dong, Eddie" <eddie.dong@xxxxxxxxx>]

Magenheimer, Dan (HP Labs Fort Collins) wrote:
> 1) Can the shared page be mapped at a fixed or guest-requested
>    virtual address for non-VTI guests?   Xen needs to guarantee
Yes, I think they are mapped by guest TR. Actually this merge doesn't
change the way PV guest map the shared page. Maybe the only difference 
is that this merge may introduce additional map for per VP VPD.
>    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.
Yes, TR map is best choice, or we can provide some kind of virtual TR
attribute 
in addition to TR and TC attribute in future.
> 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)?
Definitely we needs these variables for PV performance reason.
I would suggest to keep both vpsr and the variable used to indicate
these bits. PV guest can access vpsr.i & vpsr.ic in
seperate variable within shared page. 
>    This is critical for PV performance.  Perhaps we can
>    use "shadows" for the vpsr bits that are synchronized
>    on entry to Xen?
> 
Yes, HV can sync these variable with
vpsr before any access of VPSR that cause privop. (We also update those 
variable when vspr is updated).

The only impact to PV is that we have 2 shared page now, one for
traditional 
shared page and another one for vpd. We will use 2 TRs to map them (or
further
enhancement to use virtual TR in future)...
I know it introduce additional effort to do this in PV, kevin and I can
help together 
to make that happen if you need :)


Thanks,eddie

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