David Laight <david.lai...@aculab.com> writes: >> +#define CONTEXT_BITS 19 >> +#define USER_ESID_BITS 18 >> +#define USER_ESID_BITS_1T 6 >> + >> +/* >> + * 256MB segment >> + * The proto-VSID space has 2^(CONTEX_BITS + USER_ESID_BITS) - 1 segments >> + * available for user + kernel mapping. The top 4 contexts are used for >> + * kernel mapping. Each segment contains 2^28 bytes. Each >> + * context maps 2^46 bytes (64TB) so we can support 2^19-1 contexts >> + * (19 == 37 + 28 - 46). >> + */ > > I can't help feeling this would be easier to understand if a full > 64? 80? bit address was shown with the various bit ranges identified. > > Given the comment, I'd have expected CONTEXT_BITS to be calculated > from three other named constants - rather than being set to 19. >
May be the comments were misleading. We build proto vsid using a combination of context and ea bits. Current code does the below: for kernel: proto_vsid = ea >> SID_SHIFT; proto_vsid |= (1UL << (CONTEXT_BITS + USER_ESID_BITS)); for user: proto_vsid = ea >> SID_SHIFT proto_vsid |= context << USER_ESID_BITS context range is 0 - (2^19 -1) With this patch we _don't_ give kernel half the proto vsid range. Instead, we reduce the proto vsid range and then the kernel is given top 4 context. ie, kernel proto vsid is now for kenel: proto_vsid = ea >> SID_SHIFT; context = (MAX_CONTEXT - 4) + ((effective address >> 60) - 0xc); proto_vsid |= context << USER_ESID_BITS -aneesh _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
