[Skiboot] [PATCH] Add NX P7+ support

Dan Streetman ddstreet at ieee.org
Tue Mar 17 05:03:09 AEDT 2015


On Thu, Mar 12, 2015 at 10:59 PM, Stewart Smith
<stewart at linux.vnet.ibm.com> wrote:
> Dan Streetman <ddstreet at ieee.org> writes:
>> Add NX config register values for P7+.  Remove "P8" from all register
>> defines, where the define is common to P7+ and P8.  For values new to P8
>> (specifically 842 prefeching), only enable on P8.
>>
>> This should correctly setup the NX coprocessors on P7+ systems.
>>
>> Signed-off-by: Dan Streetman <ddstreet at ieee.org>
>> ---
>>
>> I don't have access to any P7+ bare metal system right now, so I haven't
>> tested this to verify it works on P7+, but I did verify it still works
>> on a P8 system.
>
> I have P7+ in the lab in CBR that I can test on. I guess the best way is
> with the kernel patches?

yep.  I'll resend the patch set, updated for the nx node location per
the other skiboot patch I sent.  I can provide a pre-built kernel with
the patches too if you want, either using pkvm 3.1 src or the latest
upstream kernel src.

once you get the patched kernel loaded on the system, you just need to
load the module nx-compress-powernv.  To test, you could use zswap,
although it's a bit complicated to set up; or you can use the
compression test module i added, comp_selftest.  Once you load
comp_selftest there's a debugfs interface; in the
/sys/kernel/debugfs/comp_selftest dir you can do:

echo 842 > compressor
echo 1 > running

that should start it testing, you can do
cat status

for a continually-updated status, and you can ajdust the number of
threads and other params using the other nodes in the dir.  you can
stop the test by writing 0 to the running node.  (I still plan to
adjust the interface here, breaking out each of the status info values
into their own nodes, and maybe removing the status node as you can
script a constant checking easily...)

On the P8 test systems, I was getting some pretty impressive
compression throughput (between 5-10 GBps, per thread, it seemed to be
only about 1/4 or so of the throughput of the memcpy-only null
compressor), so I'm interested to see what it looks like on the p7+
system.

>
> From a quick glance, there's nothing we can really do to abstract away
> the slight differences between P7 and P8 for kernel?

Well the kernel driver doesn't care at all about P7/P8 except for the
xscom r/w, since the xscom addrs are different between P7/P8.  As I
haven't actually added any error recovery (via xscoms) to the kernel
driver yet, I could remove the xscom stuff from the first kernel patch
set.  However, if the kernel driver is who eventually monitors and
handles NX errors, I don't see any way around r/w directly from the NX
xscoms.  The P7/P8 differences should be able to be abstracted in the
nx-842-xscom.h header though, and I don't think the actual driver will
need to know the P num.

Also, we could use skiboot to add device tree nodes telling the driver
what NX xscom register addrs to use, which would remove the P7/P8
specifics from the kernel completely, but then we rely on having to
update skiboot if we ever want to r/w a new NX xscom register in the
kernel driver, which isn't ideal.


>
> It doesn't really matter anyway, as P7 with OPAL has only ever been used
> internally for development purposes.
>

yeah, but it would be nice to be able to test on p7+ also, as you said
before there's more of them out there than P8's for people to work
with.  I managed to get 2 surplus p7+ systems myself, although they
are still being moved to our lab space.

i assume p7+ systems can be updated to fw830?


More information about the Skiboot mailing list