| Message ID | 20200506174238.15385-12-Sergey.Semin@baikalelectronics.ru (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | None | expand |
On Wed, May 06, 2020 at 08:42:29PM +0300, Sergey.Semin@baikalelectronics.ru wrote: > From: Serge Semin <Sergey.Semin@baikalelectronics.ru> > > Indeed according to the P5600/P6000 manual the MAAR pair register > address field either takes [12:31] bits for 32-bits non-XPA systems > and [12:35] otherwise. In any case the current address mask is just > wrong for 64-bit and 32-bits XPA chips. So lets extend it to 39-bits > value. This shall cover the 64-bits architecture and systems with XPA > enabled, and won't cause any problem for non-XPA 32-bit systems, since > the value will be just truncated when written to the 32-bits register. according to MIPS32 Priveleged Resoure Architecture Rev. 6.02 ADDR spans from bit 12 to bit 55. So your patch fits only for P5600. Does the wider mask cause any problems ? Thomas.
On Thu, May 07, 2020 at 01:09:51PM +0200, Thomas Bogendoerfer wrote: > On Wed, May 06, 2020 at 08:42:29PM +0300, Sergey.Semin@baikalelectronics.ru wrote: > > From: Serge Semin <Sergey.Semin@baikalelectronics.ru> > > > > Indeed according to the P5600/P6000 manual the MAAR pair register > > address field either takes [12:31] bits for 32-bits non-XPA systems > > and [12:35] otherwise. In any case the current address mask is just > > wrong for 64-bit and 32-bits XPA chips. So lets extend it to 39-bits > > value. This shall cover the 64-bits architecture and systems with XPA > > enabled, and won't cause any problem for non-XPA 32-bit systems, since > > the value will be just truncated when written to the 32-bits register. > > according to MIPS32 Priveleged Resoure Architecture Rev. 6.02 > ADDR spans from bit 12 to bit 55. So your patch fits only for P5600. > Does the wider mask cause any problems ? No, it won't. Bits written to the [40:62] range will be just ignored, while reading from there should return zeros. Setting GENMASK_ULL(55, 12) would also work. Though this solution is a bit workarounding because MIPS_MAAR_ADDR wouldn't reflect the real mask of the ADDR field. Something like the next macro would work better: +#define MIPS_MAAR_ADDR \ +({ \ + u64 __mask; \ + \ + if (cpu_has_lpa && read_c0_pagegrain() & PG_ELPA) { \ + __mask = GENMASK_ULL(55, 12); \ + else \ + __mask = GENMASK_ULL(31, 12); \ + \ + __mask; \ +}) What do you think? What is better: the macro above or setting GENMASK_ULL(55, 12)? BTW I've just figured out, that since XPA is currently only supported by kernels with CPU_MIPS32x config enabled, then only MIPS32 may have extended physical addressing of 2^60 bytes if CONFIG_XPA is enabled. Generic MIPS64 doesn't support the extended phys addressing so only 2^36 bytes are available on such platforms. (Loongson64 doesn't count, the platform code sets the PG_ELPA bit manually in kernel-entry-init.h) -Sergey > > Thomas. > > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > good idea. [ RFC1925, 2.3 ]
On Thu, May 07, 2020 at 10:13:37PM +0300, Serge Semin wrote: > On Thu, May 07, 2020 at 01:09:51PM +0200, Thomas Bogendoerfer wrote: > > On Wed, May 06, 2020 at 08:42:29PM +0300, Sergey.Semin@baikalelectronics.ru wrote: > > > From: Serge Semin <Sergey.Semin@baikalelectronics.ru> > > > > > > Indeed according to the P5600/P6000 manual the MAAR pair register > > > address field either takes [12:31] bits for 32-bits non-XPA systems > > > and [12:35] otherwise. In any case the current address mask is just > > > wrong for 64-bit and 32-bits XPA chips. So lets extend it to 39-bits > > > value. This shall cover the 64-bits architecture and systems with XPA > > > enabled, and won't cause any problem for non-XPA 32-bit systems, since > > > the value will be just truncated when written to the 32-bits register. > > > > according to MIPS32 Priveleged Resoure Architecture Rev. 6.02 > > ADDR spans from bit 12 to bit 55. So your patch fits only for P5600. > > > Does the wider mask cause any problems ? > > No, it won't. Bits written to the [40:62] range will be just ignored, > while reading from there should return zeros. Setting GENMASK_ULL(55, 12) > would also work. Though this solution is a bit workarounding because > MIPS_MAAR_ADDR wouldn't reflect the real mask of the ADDR field. Something > like the next macro would work better: > > +#define MIPS_MAAR_ADDR \ > +({ \ > + u64 __mask; \ > + \ > + if (cpu_has_lpa && read_c0_pagegrain() & PG_ELPA) { \ > + __mask = GENMASK_ULL(55, 12); \ > + else \ > + __mask = GENMASK_ULL(31, 12); \ > + \ > + __mask; \ > +}) that looks horrible. > What do you think? What is better: the macro above or setting > GENMASK_ULL(55, 12)? just that one ;-) Thomas.
On Fri, May 08, 2020 at 11:22:36AM +0200, Thomas Bogendoerfer wrote: > On Thu, May 07, 2020 at 10:13:37PM +0300, Serge Semin wrote: > > On Thu, May 07, 2020 at 01:09:51PM +0200, Thomas Bogendoerfer wrote: > > > On Wed, May 06, 2020 at 08:42:29PM +0300, Sergey.Semin@baikalelectronics.ru wrote: > > > > From: Serge Semin <Sergey.Semin@baikalelectronics.ru> > > > > > > > > Indeed according to the P5600/P6000 manual the MAAR pair register > > > > address field either takes [12:31] bits for 32-bits non-XPA systems > > > > and [12:35] otherwise. In any case the current address mask is just > > > > wrong for 64-bit and 32-bits XPA chips. So lets extend it to 39-bits > > > > value. This shall cover the 64-bits architecture and systems with XPA > > > > enabled, and won't cause any problem for non-XPA 32-bit systems, since > > > > the value will be just truncated when written to the 32-bits register. > > > > > > according to MIPS32 Priveleged Resoure Architecture Rev. 6.02 > > > ADDR spans from bit 12 to bit 55. So your patch fits only for P5600. > > > > > Does the wider mask cause any problems ? > > > > No, it won't. Bits written to the [40:62] range will be just ignored, > > while reading from there should return zeros. Setting GENMASK_ULL(55, 12) > > would also work. Though this solution is a bit workarounding because > > MIPS_MAAR_ADDR wouldn't reflect the real mask of the ADDR field. Something > > like the next macro would work better: > > > > +#define MIPS_MAAR_ADDR \ > > +({ \ > > + u64 __mask; \ > > + \ > > + if (cpu_has_lpa && read_c0_pagegrain() & PG_ELPA) { \ > > + __mask = GENMASK_ULL(55, 12); \ > > + else \ > > + __mask = GENMASK_ULL(31, 12); \ > > + \ > > + __mask; \ > > +}) > > that looks horrible. > > > What do you think? What is better: the macro above or setting > > GENMASK_ULL(55, 12)? > > just that one ;-) Agreed. I'll fix it in v3. -Sergey > > Thomas. > > -- > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > good idea. [ RFC1925, 2.3 ]
diff --git a/arch/mips/include/asm/mipsregs.h b/arch/mips/include/asm/mipsregs.h index 039ebd913f00..165f6318d861 100644 --- a/arch/mips/include/asm/mipsregs.h +++ b/arch/mips/include/asm/mipsregs.h @@ -775,7 +775,7 @@ /* MAAR bit definitions */ #define MIPS_MAAR_VH (_U64CAST_(1) << 63) -#define MIPS_MAAR_ADDR ((BIT_ULL(BITS_PER_LONG - 12) - 1) << 12) +#define MIPS_MAAR_ADDR GENMASK_ULL(35, 12) #define MIPS_MAAR_ADDR_SHIFT 12 #define MIPS_MAAR_S (_ULCAST_(1) << 1) #define MIPS_MAAR_VL (_ULCAST_(1) << 0)