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

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

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