WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ppc-devel

Re: [XenPPC] performance profiling current and future steps


On Mar 23, 2007, at 9:07 AM, Hollis Blanchard wrote:

On Fri, 2007-03-23 at 08:52 +0100, Christian Ehrhardt wrote:
Jimi Xenidis wrote:
...
Ensure MMCR0[FCH] for this first step:
-(ensure) set MMCR[FCH] always in xen when entering xen space. This
should prevent a domain
 messing up MMCR0[FCH]
->EXCEPTION_HEAD in exception.S set MMCR0[FCH] always

You need at least the following instructions:
    mfspr r0, SPRN_MMCR0
    ori r0, r0, 1 /* MMRC0_FCH */
    mtspr 795, SPRN_MMCR0

Unfortuantely, there is not enough room in EXCEPTION_HEAD for that and
you will get:

  exceptions.S: Assembler messages:
  exceptions.S:246: Error: attempt to .org/.space backwards? (-4)
  exceptions.S:253: Error: attempt to .org/.space backwards? (-4)
  exceptions.S:260: Error: attempt to .org/.space backwards? (-4)
  exceptions.S:267: Error: attempt to .org/.space backwards? (-4)
  exceptions.o: Bad value
  exceptions.S:626: FATAL: Can't write exceptions.o: Bad value


I suggest we start a new macro PMU_SAVE_STATE(save,scratch), which
does the above (for now, using only scratch) and sprinkling it in all
the code that EXCEPTION_HEAD branches to.

Yep, I had those already:
         mfspr r0,SPRN_MMCR0             /* ensure MMCR0[FCH]=1 */
         ori r0,r0,MMCR0_FCH
         mtspr SPRN_MMCR0, r0

Do you mean to insert a branch to PMU_SAVE_STATE from EXCEPTION_HEAD or to put a PMU_SAVE_STATE branch to every section calling EXCEPTION_HEAD ?
Can someone please point at a code piece that does a similar macro
definition and branch already.

We have 0x80 bytes for the "top half" of our exception handlers. This is dictated by hardware: there are vectors at 0x300 and 0x380, so our code must fit in that much space. If you do the math, that means we have room
for 32 instructions, including a branch to the rest of the handler
(named "ex_*_continued"). Right now, we use 30 instructions. So without doing major exception handler surgery, your three new instructions will
need to go after the branch.

Side note: I think it's ridiculous that our architecture allows the
guest to set MMCR0:FCH, since that bit controls the CPU while in
hypervisor mode. Anyways, disabling that bit a few dozen instructions
later shouldn't make a difference, and the domain never should have set
it in the first place.

Alternatively we could setup an "assist" session with screen -x
developing this part together if there is a volunteer.

I created this one blindly now as a start

     .macro PMU_SAVE_STATE save scratch
mfspr \scratch,SPRN_MMCR0 /* ensure MMCR0[FCH] =1,
not yet saving anything */
         ori \scratch,\scratch,MMCR0_FCH
         mtspr SPRN_MMCR0, \scratch
     .endm

and added the following to EXCEPTION_HEAD, but I guess it it wrong that
way ;)

     PMU_SAVE_STATE r0 r0

Right, that won't fit in EXCEPTION_HEAD (you will get the assembler
error messages Jimi pasted above).

Yeah,
So EXCEPTION_HEAD branches to a passed in label. Find all those labels and insert PMU_SAVE_STATE there.

-JX



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