Unexpected variation in SYS_ID_AA64MMFR0_EL1

Unexpected variation in SYS_ID_AA64MMFR0_EL1

[Marc Gonzalez]

Hello,

On an APQ8098-based system, for cores 4-7 (little cores?), the kernel prints:

[    0.179055] CPU features: SANITY CHECK: Unexpected variation in SYS_ID_AA64MMFR0_EL1.
Boot CPU: 0x00000000001122, CPU4: 0x00000000101122

TGran16, [23:20]
    Support for 16KB memory translation granule size:
	0x1	Indicates that the 16KB granule is supported.

Since this is a pr_warn, I get the feeling something is not quite right.
Is there something to fix? Is it a problem that the big and little cores
don't support exactly the same granule sizes?

Regards.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Unexpected variation in SYS_ID_AA64MMFR0_EL1

[Ard Biesheuvel]

On Fri, 30 Nov 2018 at 13:15, Marc Gonzalez <marc.w.gonzalez@free.fr> wrote:
>
> Hello,
>
> On an APQ8098-based system, for cores 4-7 (little cores?), the kernel prints:
>
> [    0.179055] CPU features: SANITY CHECK: Unexpected variation in SYS_ID_AA64MMFR0_EL1.
> Boot CPU: 0x00000000001122, CPU4: 0x00000000101122
>
> TGran16, [23:20]
>     Support for 16KB memory translation granule size:
>         0x1     Indicates that the 16KB granule is supported.
>
> Since this is a pr_warn, I get the feeling something is not quite right.
> Is there something to fix? Is it a problem that the big and little cores
> don't support exactly the same granule sizes?
>

That looks like a false positive to me. We should only care about the
page size we are running with.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Unexpected variation in SYS_ID_AA64MMFR0_EL1

[Suzuki K Poulose]

On 30/11/2018 13:12, Ard Biesheuvel wrote:
> On Fri, 30 Nov 2018 at 13:15, Marc Gonzalez <marc.w.gonzalez@free.fr> wrote:
>>
>> Hello,
>>
>> On an APQ8098-based system, for cores 4-7 (little cores?), the kernel prints:
>>
>> [    0.179055] CPU features: SANITY CHECK: Unexpected variation in SYS_ID_AA64MMFR0_EL1.
>> Boot CPU: 0x00000000001122, CPU4: 0x00000000101122
>>
>> TGran16, [23:20]
>>      Support for 16KB memory translation granule size:
>>          0x1     Indicates that the 16KB granule is supported.
>>
>> Since this is a pr_warn, I get the feeling something is not quite right.
>> Is there something to fix? Is it a problem that the big and little cores
>> don't support exactly the same granule sizes?
>>
> 
> That looks like a false positive to me. We should only care about the
> page size we are running with.

Unless you run a VM, which is going to use 16K translation. But this may be
fine with the current kernels, where we emulate the SANITISED registers
for the guests.

Cheers
Suzuki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Unexpected variation in SYS_ID_AA64MMFR0_EL1

[Ard Biesheuvel]

On Fri, 30 Nov 2018 at 14:23, Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
>
>
>
> On 30/11/2018 13:12, Ard Biesheuvel wrote:
> > On Fri, 30 Nov 2018 at 13:15, Marc Gonzalez <marc.w.gonzalez@free.fr> wrote:
> >>
> >> Hello,
> >>
> >> On an APQ8098-based system, for cores 4-7 (little cores?), the kernel prints:
> >>
> >> [    0.179055] CPU features: SANITY CHECK: Unexpected variation in SYS_ID_AA64MMFR0_EL1.
> >> Boot CPU: 0x00000000001122, CPU4: 0x00000000101122
> >>
> >> TGran16, [23:20]
> >>      Support for 16KB memory translation granule size:
> >>          0x1     Indicates that the 16KB granule is supported.
> >>
> >> Since this is a pr_warn, I get the feeling something is not quite right.
> >> Is there something to fix? Is it a problem that the big and little cores
> >> don't support exactly the same granule sizes?
> >>
> >
> > That looks like a false positive to me. We should only care about the
> > page size we are running with.
>
> Unless you run a VM, which is going to use 16K translation.

Good point.

> But this may be
> fine with the current kernels, where we emulate the SANITISED registers
> for the guests.
>
> Cheers
> Suzuki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Unexpected variation in SYS_ID_AA64MMFR0_EL1

[Catalin Marinas]

On Fri, Nov 30, 2018 at 01:23:28PM +0000, Suzuki K. Poulose wrote:
> On 30/11/2018 13:12, Ard Biesheuvel wrote:
> > On Fri, 30 Nov 2018 at 13:15, Marc Gonzalez <marc.w.gonzalez@free.fr> wrote:
> > > On an APQ8098-based system, for cores 4-7 (little cores?), the kernel prints:
> > > 
> > > [    0.179055] CPU features: SANITY CHECK: Unexpected variation in SYS_ID_AA64MMFR0_EL1.
> > > Boot CPU: 0x00000000001122, CPU4: 0x00000000101122
> > > 
> > > TGran16, [23:20]
> > >      Support for 16KB memory translation granule size:
> > >          0x1     Indicates that the 16KB granule is supported.
> > > 
> > > Since this is a pr_warn, I get the feeling something is not quite right.
> > > Is there something to fix? Is it a problem that the big and little cores
> > > don't support exactly the same granule sizes?
> > > 
> > 
> > That looks like a false positive to me. We should only care about the
> > page size we are running with.
> 
> Unless you run a VM, which is going to use 16K translation. But this may be
> fine with the current kernels, where we emulate the SANITISED registers
> for the guests.

I think that's sanitised now for KVM, so we could downgrade the feature
to FTR_NONSTRICT.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Unexpected variation in SYS_ID_AA64MMFR0_EL1

[Suzuki K Poulose]

On 03/12/2018 15:32, Catalin Marinas wrote:
> On Fri, Nov 30, 2018 at 01:23:28PM +0000, Suzuki K. Poulose wrote:
>> On 30/11/2018 13:12, Ard Biesheuvel wrote:
>>> On Fri, 30 Nov 2018 at 13:15, Marc Gonzalez <marc.w.gonzalez@free.fr> wrote:
>>>> On an APQ8098-based system, for cores 4-7 (little cores?), the kernel prints:
>>>>
>>>> [    0.179055] CPU features: SANITY CHECK: Unexpected variation in SYS_ID_AA64MMFR0_EL1.
>>>> Boot CPU: 0x00000000001122, CPU4: 0x00000000101122
>>>>
>>>> TGran16, [23:20]
>>>>       Support for 16KB memory translation granule size:
>>>>           0x1     Indicates that the 16KB granule is supported.
>>>>
>>>> Since this is a pr_warn, I get the feeling something is not quite right.
>>>> Is there something to fix? Is it a problem that the big and little cores
>>>> don't support exactly the same granule sizes?
>>>>
>>>
>>> That looks like a false positive to me. We should only care about the
>>> page size we are running with.
>>
>> Unless you run a VM, which is going to use 16K translation. But this may be
>> fine with the current kernels, where we emulate the SANITISED registers
>> for the guests.
> 
> I think that's sanitised now for KVM, so we could downgrade the feature
> to FTR_NONSTRICT.
> 

Yes, the only caveat is we must make sure that the patch somehow reflect
the KVM changes to prevent backports assuming that it is safe to change them
without the KVM bits.

I will cook something up, along with the other feature bits.

Cheers
Suzuki

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: Unexpected variation in SYS_ID_AA64MMFR0_EL1

[Catalin Marinas]

On Wed, Dec 05, 2018 at 10:17:38AM +0000, Suzuki K Poulose wrote:
> 
> 
> On 03/12/2018 15:32, Catalin Marinas wrote:
> > On Fri, Nov 30, 2018 at 01:23:28PM +0000, Suzuki K. Poulose wrote:
> > > On 30/11/2018 13:12, Ard Biesheuvel wrote:
> > > > On Fri, 30 Nov 2018 at 13:15, Marc Gonzalez <marc.w.gonzalez@free.fr> wrote:
> > > > > On an APQ8098-based system, for cores 4-7 (little cores?), the kernel prints:
> > > > > 
> > > > > [    0.179055] CPU features: SANITY CHECK: Unexpected variation in SYS_ID_AA64MMFR0_EL1.
> > > > > Boot CPU: 0x00000000001122, CPU4: 0x00000000101122
> > > > > 
> > > > > TGran16, [23:20]
> > > > >       Support for 16KB memory translation granule size:
> > > > >           0x1     Indicates that the 16KB granule is supported.
> > > > > 
> > > > > Since this is a pr_warn, I get the feeling something is not quite right.
> > > > > Is there something to fix? Is it a problem that the big and little cores
> > > > > don't support exactly the same granule sizes?
> > > > > 
> > > > 
> > > > That looks like a false positive to me. We should only care about the
> > > > page size we are running with.
> > > 
> > > Unless you run a VM, which is going to use 16K translation. But this may be
> > > fine with the current kernels, where we emulate the SANITISED registers
> > > for the guests.
> > 
> > I think that's sanitised now for KVM, so we could downgrade the feature
> > to FTR_NONSTRICT.
> 
> Yes, the only caveat is we must make sure that the patch somehow reflect
> the KVM changes to prevent backports assuming that it is safe to change them
> without the KVM bits.

We can add a "Cc: stable # <commit-that-fixes-KVM>" to make the
requirement clear. We should probably also limit the Cc: stable to the
kernel version where KVM started trapping this register.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel