[Cbe-oss-dev] [PATCH 2/2] Add support for dumping spu info from xmon
Geoff Levand
geoffrey.levand at am.sony.com
Fri Nov 10 20:11:12 EST 2006
Michael Ellerman wrote:
> On Thu, 2006-10-12 at 10:42 -0700, Geoff Levand wrote:
>> Michael Ellerman wrote:
>> > This patch adds a command to xmon for dumping information about
>> > spu structs. The command is 'sf' for "spu fields" perhaps, and
>> > takes the spu number as an argument. This is the same value as the
>> > spu->number field, or the "phys-id" value of a context when it is
>> > bound to a physical spu.
>>
>> > +static void dump_spu_fields(struct spu *spu)
>> > +{
>> ...
>> > + DUMP_FIELD(spu, "0x%x", problem->spu_npc_RW);
>> > + DUMP_FIELD(spu, "0x%p", priv1);
>> > +
>> > + if (spu->priv1)
>> > + DUMP_FIELD(spu, "0x%lx", priv1->mfc_sr1_RW);
>> > +
>> > + DUMP_FIELD(spu, "0x%p", priv2);
>>
>> Just to let you know, I've been doing some work to abstract the platform
>> specific parts out of the spu support to better support running on a
>> hypervisor. It shouldn't make much difference, but maybe I'll try to set
>> something up like this for you:
>>
>> DUMP_FIELD(spu, "0x%x", problem->spu_npc_RW);
>> DUMP_FIELD(spu, "0x%p", priv2);
>> spu_dump_platform_fields(spu);
>
> We already have the spu_priv1_ops abstracted out, is that not enough? I
> decided to check explicitly for the priv1 pointer because calling the
> hypervisor from a panicked kernel is risky at best. Although I haven't
> seen how you guys implement hypervisor calls, so perhaps it's not so
> bad.
Michael,
I tried to set this up as above, but unfortunately, your DUMP_FIELD is
setup in such a way that it is not easy to change to use from outside
xmon.c, so I left spu_dump_platform_fields() (I put it in spu_priv1_mmio.c)
empty. We'll need to work on something usable here, or make some other way
to abstract those platform specific spu variables.
I'll re-post my abstract spu management routines patch again soon with
this xmon support added.
-Geoff
More information about the cbe-oss-dev
mailing list