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

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

Dan:
        Finally noticed the term "physical" here you mean machine. I.e
using machine TR for shared info.
        I think this problem doesn't relate to vcpu context merge
(actually it is a TLB related issue). The merge will guarantee both VTI
and Non-VTI work. (A simple way to do that is to use 2 TR now).
get_ctrl_if issue is also not related to merge.
Eddie

Dong, Eddie wrote:
> Magenheimer, Dan (HP Labs Fort Collins) wrote:
>> 
>> This particular "virtual TR" is critical so might warrant a
>> separate hypercall.  I need to ensure that the shared page is Great!
>> We are same here. pinned (in a physical TR) for performance in the
>> guest 
> It is pinned definitely no matter guest physical TR or guest physical
> virtual TR
> (physical virtual TR is actually a physical TC but will not be
> automatically purged).
>> and because I access it with psr.ic off in Xen itself.  (The
> Yes, it is pinned so you can use it when vpsr.ic=0.
>> physical TR and virtual address could be different but that
>> seems like a waste of precious TRs.)
> Not sure what you mean here. Guest physical TR is always backed by
> machine TC.
> 
>> 
>> 
>> Found it.  See #define get_ctrl_if() in ctrl_if.c (2048 not 1024,
>> which is why I couldn't find it).
> Why do u think the merge will change this? The major proposal of
> structure merge
> is to remove parts of guest CR contents into shared VPD that means the
> size of share
> info is reduced. In this way the merge will make things better than
> original one.
> Eddie
> 
> _______________________________________________
> Xen-ia64-devel mailing list
> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-ia64-devel


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