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

["Xu, Anthony" <anthony.xu@xxxxxxxxx>]

Dan,
Thanks for your sharing,
This will definitely help developers in community greatly.

I still have some questions.

>into a privileged instruction.  This meant I couldn't
>always just use a "break" instruction.
I don't understand this, is this because fc has a parameter?
But I don't think it is a big deal.

*       mov rx=ar.cflg -> mov ar.cflg=r(x+64) [**]
Did you find linux kernel use ar.cflg?

Thanks,
-Anthony 
>-----Original Message-----
>From: Magenheimer, Dan (HP Labs Fort Collins) [mailto:dan.magenheimer@xxxxxx]
>Sent: 2006年3月11日 1:35
>To: Tristan Gingold; Xu, Anthony
>Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>Subject: RE: [Xen-ia64-devel]Question about priv_ptc_e
>
>> 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_Tech
>nical_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