Skip to content

VPHN parsing fixes

Greg Kurz linuxppc-dev 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest3 patches 0 repliesNew

Patches in v1 No applies recorded yet

#Subject and filesSizeRepliesApplied
1/3powerpc/vphn: clarify the H_HOME_NODE_ASSOCIATIVITY APIarch/powerpc/mm/numa.c+6 -20 replies
2/3powerpc/vphn: simplify the parsing codearch/powerpc/mm/numa.c+8 -120 replies
3/3powerpc/vphn: move endianness fixing to vphn_unpack_associativity()arch/powerpc/mm/numa.c+29 -130 replies

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [PATCH 0/3] VPHN parsing fixes

The following commit fixed an endianness issue in the VPHN code:

commit 5c9fb1899400096c6818181c525897a31d57e488

Author: Greg Kurz <[email protected]>
Date:   Wed Oct 15 12:42:58 2014 +0200

powerpc/vphn: NUMA node code expects big-endian

It was discussed at the time that we should patch the parsing code instead of boldly fixing all the values returned by the hypervisor. It is the goal of this series.

I have an extra question: PAPR+ says that H_HOME_NODE_ASSOCIATIVITY is supposed
to populate registers R4 to R9 with 16-bit or 32-bit values. This means that we
could theorically get 24 associativity domain numbers. According to this commentthe code is limited to 12 though:

/*
* 6 64-bit registers unpacked into 12 32-bit associativity values. To form
* the complete property we have to add the length in the first cell. */
#define VPHN_ASSOC_BUFSIZE (VPHN_REGISTER_COUNT*sizeof(u64)/sizeof(u32) + 1)

I could find no justification for the fact that we don't expect the registers to hold 16-bit relevant numbers only. Have I missed something ?

---

Greg Kurz (3):
powerpc/vphn: clarify the H_HOME_NODE_ASSOCIATIVITY API powerpc/vphn: simplify the parsing code
powerpc/vphn: move endianness fixing to vphn_unpack_associativity()

 arch/powerpc/mm/numa.c |   61 ++++++++++++++++++++++++++++++------------------
 1 file changed, 38 insertions(+), 23 deletions(-)

--
Greg