The proto VSID is built using both the MMU context id and effective
segment ID (ESID). We should not have overlapping bits between those.
That could result in us having a VSID collision. With the current code
we missed masking the top bits of the ESID. This implies for kernel
address we ended up using the top 4 bits of the ESID as part of the
proto VSID, which is wrong.
The current code use the top 4 context values (0x7fffc - 0x7ffff) for
the kernel. With those context IDs used for the kernel, we don't run
into VSID collisions because we get the same proto VSID irrespective of
whether we mask the ESID bits or not. eg:
ea = 0xf000000000000000
context = 0x7ffff
w/out masking:
proto_vsid = (0x7ffff << 6 | 0xf000000000000000 >> 40)
= (0x1ffffc0 | 0xf00000)
= 0x1ffffc0
with masking:
proto_vsid = (0x7ffff << 6 | ((0xf000000000000000 >> 40) & 0x3f))
= (0x1ffffc0 | (0xf00000 & 0x3f))
= 0x1ffffc0 | 0)
= 0x1ffffc0
So although there is no bug, the code is still overly subtle, so fix it
to save ourselves pain in future.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
#define ESID_BITS 18
#define ESID_BITS_1T 6
+#define ESID_BITS_MASK ((1 << ESID_BITS) - 1)
+#define ESID_BITS_1T_MASK ((1 << ESID_BITS_1T) - 1)
+
/*
* 256MB segment
* The proto-VSID space has 2^(CONTEX_BITS + ESID_BITS) - 1 segments
if (ssize == MMU_SEGSIZE_256M)
return vsid_scramble((context << ESID_BITS)
- | (ea >> SID_SHIFT), 256M);
+ | ((ea >> SID_SHIFT) & ESID_BITS_MASK), 256M);
return vsid_scramble((context << ESID_BITS_1T)
- | (ea >> SID_SHIFT_1T), 1T);
+ | ((ea >> SID_SHIFT_1T) & ESID_BITS_1T_MASK), 1T);
}
/*