[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: "Magenheimer, Dan \(HP Labs Fort Collins\)" <dan.magenheimer@xxxxxx>
  • From: "Dong, Eddie" <eddie.dong@xxxxxxxxx>
  • Date: Thu, 26 May 2005 07:07:37 +0800
  • Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 25 May 2005 23:06:59 +0000
  • List-id: DIscussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
  • Thread-index: AcVbe1RkD/iHinBzT3SB7w1CGdFiMQBEFR/wACTyKtAAEZ7HwAB3g3MgAIEYpkAACkirgA==
  • Thread-topic: vcpu context merge

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.