RE: [Xen-ia64-devel] Returning the kr's to the guest

["Yang, Fred" <fred.yang@xxxxxxxxx>]

Dan,
This is a very interest idea!  This will definitely help merging VT-I
and non-VT-I one step closer.
We are very interest in this, and are working on an internal proposal
now.  We will send the proposal ASAP, Thanks,
-Fred

Magenheimer, Dan (HP Labs Fort Collins) wrote:
> Something that I've been thinking about for a long
> time but haven't gotten around to trying, so I thought
> I'd post it for discussion and perhaps somebody else
> in the community might have some time to develop
> (and thoroughly test) a patch:
> 
> In the current Xen/ia64 design, the eight ia64 kernel
> registers are "owned" by Xen.  The kr's are privilege-
> sensitive; that is, writes to the registers are
> privileged and reads are unprivileged.  As such,
> the current Xen design reserves the kr's for the
> privileged kernel, which is Xen itself.  And all
> guest uses of kr's (both read and write) are either
> trapped and emulated or paravirtualized.
> 
> This was expedient but may have been a poor design
> choice.  A guest generally reads the kernel registers
> more than it writes them.  In the current xenlinux
> paravirtualization, performance of kr access is
> not really a problem (indeed it may even be faster
> than reading the physical kr's... which are known to
> be quite slow).  But taking the kr's away from the
> guest is error prone for future paravirtualizations;
> two recent paravirtualization bugs were found where
> kr reads were not paravirtualized.
> 
> As such, I'd be inclined to change the design to let
> the guest own the kr's and convert all uses of kr's
> in Xen itself to instead use a per-cpu array, which
> is currently pinned by a TR.  (There aren't many uses
> of the kr's in Xen but they are nearly all in assembly
> code.)
> 
> Comments?
> 
> If this is something you are interested in generating
> a patch for, please develop the patch with liberal
> use of a #ifdef, so we can easily toggle between
> Xen-owns-krs and guest-owns-krs.  This will allow
> us to compare the performance difference (which I expect
> to be negligible, but one never knows...) Note that a
> good first step might be to change only Xen so that
> *neither* uses the krs, then later xenlinux can be changed
> without requiring the change to be synchronized.
> 
> Dan
> 
> _______________________________________________
> 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