RE: [Xen-ia64-devel]Question about priv_ptc_e

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

> From: Tristan Gingold [mailto:Tristan.Gingold@xxxxxxxx] 
> Sent: Friday, March 10, 2006 2:41 AM
> To: Xu, Anthony; Magenheimer, Dan (HP Labs Fort Collins)
> Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-ia64-devel]Question about priv_ptc_e
> 
> Le Vendredi 10 Mars 2006 09:27, Xu, Anthony a Ãcrit :
> > From: Tristan Gingold [mailto:Tristan.Gingold@xxxxxxxx]
> >
> > >Sent: 2006å3æ10æ 16:13
> > >This is the way fc is privatized.
> > >You need to privatize fc because its semantic is different 
> in CPL0 and CPL
> > > != 0.  You couldn't use a break (at least during the 
> privatize area), so
> > > Dan used a priv op with special registers.
> > >
> > >Maybe this area is over and this could be now cleaned.
> >
> > Understand, so the question changes to,
> > Doesn't fc use register whose index is larger than 63?
> It may, but it don't.
> I suppose privatize checks this.  According to Dan work, the 
> answer is no.
> Note we only speak about fc in kernel.

Sorry for the delayed response...

It would be OK to clean this up.  It may actually be
causing a bug!  But I would like to preserve the code
rather than remove it as it is possible that it may
be used again.  It would be OK though to tie it to a
global variable / command line option that defaults
off.  For example:

 // NOTE: ptc_e with source gr > 63 is emulated as a fc r(y-64)
-       if (src > 63) return(vcpu_fc(vcpu,vcpu_get_gr(vcpu,src - 64)));
+       if (privified && src > 63)
+               return(vcpu_fc(vcpu,vcpu_get_gr(vcpu,src - 64)));
        return vcpu_ptc_e(vcpu,vcpu_get_gr(vcpu,src));

There are several of these that need to be changed,
so let's change all of them the same way at the same time.

Now for the complete historical explanation:

Early in the implementation of Xen/ia64, before there was
a paravirtualized Xenlinux/ia64, I implemented a program
to go through the load image of a Linux binary and convert
all "privilege-sensitive" instructions into instructions
that would trap.  Using this binary conversion, it was
possible to run an otherwise unmodified Linux on top of
Xen, albeit very slowly.  This made it possible to do a
lot of Xen/ia64 development and debugging without needing
a paravirtualized domain0.

I called this tool "privify" -- which is not an English
word.  The "-ify" suffix means "to form into" or "make
similar to" (and according to my dictionary is derived
from Old French "-fier"!).  So "privify" means "to make
into privileged instructions".

Because of the complex encodings of Itanium bundles, and
because I didn't want the privify tool to deal with
difficult cross-bundle rewriting, I needed to carefully
choose how to transform each privilege-sensitive instruction
into a privileged instruction.  This meant I couldn't
always just use a "break" instruction.  Furthermore, since Xen
was going to emulate the transformed instructions
differently than the actual privileged instruction, I
needed to choose privileged instructions that were never
(or at least very rarely) used.

I noted that nearly all instructions that use general
registers are capable of accessing all 128 GR's, but
it is rare for gr64-127 to be accessed.  And it is
VERY rare for those registers to get accessed by a
privileged instructions.   So the privify program
transforms privilege-sensitive instruction into other
highly similar privileged instructions.  In the example
you noted:

   "fc rx" is converted to "ptc r(x+64)"

Other examples include:

   thash rx=ry -> tak rx=r(y+64)
   ttag rx=ry -> tpa rx=r(y+64)

The complete list is in xen/arch/ia64/tools/privify/privify.h.
(Note that the conversion of kernel register (ar.kr) reads
pre-dates the decision to allow the kernel registers to
be owned by the guest rather than by Xen itself.)

Purists will note that this conversion is risky as it
is POSSIBLE that Xen will confuse privified instructions
with real privileged instructions.  For example, if
a guest really wanted to execute a "ptc r65" instruction,
Xen would emulate a "fc r1" instruction.  Fortunately,
except for self-modifying code, these conflicts can be
detected statically and privify warns when it encounters
one of these.  In all of Linux/ia64, there was one case
where this was a problem:  One of the mca routines had
a huge routine that utilized the higher registers and
used some privileged instructions.  If this routine got
executed, privified Linux/ia64 crashed, but there was an
easy workaround: specify "nomca" on the domain0 command
line.  (Some of you may still have "nomca" in your
elilo.conf files; this explains why!).

Privification is not perfect but it was useful and is still
interesting.  By converting privilege-sensitive instructions
so that they trap and leaving all privileged instructions
to be emulated by Xen, the number of privileged traps is
similar to the number of traps required for an unmodified
guest executing under VT-i.  With this it is possible to
approximate the performance of a fully-virtualized guest.
(Haavard Bjerke's thesis last summer provides benchmarks.)
http://openlab-mu-internal.web.cern.ch/openlab-mu-internal/Documents/2_Technical_Documents/Master_thesis/Thesis_HarvardBjerke.pdf

So this is why some privileged instruction emulation routines
in Xen/ia64 check for a register greater than 63 and do
something different.

THE END... are you sleepy yet? :-)

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