arch/riscv: SV48 patch series questions

arch/riscv: SV48 patch series questions

[Leyfoon Tan]

Hi Palmer

Alex's "Introduce sv48 support without relocatable kernel" patch series in [1] was partially merged to Linux v5.17. But there are 4 patches are not merged (Patch-10 to 13).

May I know what is the plan for these patches? Will them merged to next v5.19 merging window? Or do you expect any changes for these patches or Alex needs resend with rebase to latest kernel version?

Note, we would like to use the Patch-13 in this series.

Patches not merged:
[v3,10/13] riscv: Improve virtual kernel memory layout dump
[v3,11/13] Documentation: riscv: Add sv48 description to VM layout
[v3,12/13] riscv: Initialize thread pointer before calling C functions
[v3,13/13] riscv: Allow user to downgrade to sv39 when hw supports sv48 if !KASAN

[1]: https://patchwork.kernel.org/project/linux-riscv/cover/20211206104657.433304-1-alexandre.ghiti@canonical.com/

Thanks.

Regards
Ley Foon

Re: arch/riscv: SV48 patch series questions

[Palmer Dabbelt]

On Fri, 27 May 2022 02:37:34 PDT (-0700), leyfoon.tan@starfivetech.com wrote:
> Hi Palmer
>
> Alex's "Introduce sv48 support without relocatable kernel" patch series in [1] was partially merged to Linux v5.17. But there are 4 patches are not merged (Patch-10 to 13).
>
> May I know what is the plan for these patches? Will them merged to next v5.19 merging window? Or do you expect any changes for these patches or Alex needs resend with rebase to latest kernel version?

I just saw this as I was digging up Alex's old email to reply to, all 
but #13 are now on for-next.

> Note, we would like to use the Patch-13 in this series.

Is your use case a CPU errata?  If so I think we should just go ahead 
and add that errata via the existing errata mechanism.  If you've got 
some other use case, do you mind elaborating?  From that other thread it 
sounds like a command-line argument is the way to go for folks who want 
to turn this off more dynamically, but happy to hear if you've got 
something different in mind.

> Patches not merged:
> [v3,10/13] riscv: Improve virtual kernel memory layout dump
> [v3,11/13] Documentation: riscv: Add sv48 description to VM layout
> [v3,12/13] riscv: Initialize thread pointer before calling C functions
> [v3,13/13] riscv: Allow user to downgrade to sv39 when hw supports sv48 if !KASAN
>
> [1]: https://patchwork.kernel.org/project/linux-riscv/cover/20211206104657.433304-1-alexandre.ghiti@canonical.com/
>
> Thanks.
>
> Regards
> Ley Foon

RE: arch/riscv: SV48 patch series questions

[Leyfoon Tan]

> -----Original Message-----
> From: Palmer Dabbelt <palmer@dabbelt.com>
> Sent: Thursday, 2 June, 2022 11:44 AM
> To: Leyfoon Tan <leyfoon.tan@starfivetech.com>
> Cc: alexandre.ghiti@canonical.com; linux-riscv@lists.infradead.org; linux-
> kernel@vger.kernel.org
> Subject: Re: arch/riscv: SV48 patch series questions
> 
> On Fri, 27 May 2022 02:37:34 PDT (-0700), leyfoon.tan@starfivetech.com
> wrote:
> > Hi Palmer
> >
> > Alex's "Introduce sv48 support without relocatable kernel" patch series in
> [1] was partially merged to Linux v5.17. But there are 4 patches are not
> merged (Patch-10 to 13).
> >
> > May I know what is the plan for these patches? Will them merged to next
> v5.19 merging window? Or do you expect any changes for these patches or
> Alex needs resend with rebase to latest kernel version?
> 
> I just saw this as I was digging up Alex's old email to reply to, all but #13 are
> now on for-next.
> 
> > Note, we would like to use the Patch-13 in this series.
> 
> Is your use case a CPU errata?  If so I think we should just go ahead and add
> that errata via the existing errata mechanism.  If you've got some other use
> case, do you mind elaborating?  From that other thread it sounds like a
> command-line argument is the way to go for folks who want to turn this off
> more dynamically, but happy to hear if you've got something different in
> mind.
It is not CPU errata. 
RISC-V cpu can have sv39, sv48 or even sv57. If it is a heterogenous system, cpu cores in the system might have different sv. Eg: one cpu can be sv39 and another core is sv48.
In this case, auto detection is not work. So, Patch-13 can help in this use case.

> 
> > Patches not merged:
> > [v3,10/13] riscv: Improve virtual kernel memory layout dump [v3,11/13]
> > Documentation: riscv: Add sv48 description to VM layout [v3,12/13]
> > riscv: Initialize thread pointer before calling C functions [v3,13/13]
> > riscv: Allow user to downgrade to sv39 when hw supports sv48 if !KASAN
> >
> > [1]:
> > https://patchwork.kernel.org/project/linux-riscv/cover/20211206104657.
> > 433304-1-alexandre.ghiti@canonical.com/
> >

Thanks.

Regards
Ley Foon

RE: arch/riscv: SV48 patch series questions

[Leyfoon Tan]

> -----Original Message-----
> From: Leyfoon Tan
> Sent: Thursday, 2 June, 2022 1:44 PM
> To: 'Palmer Dabbelt' <palmer@dabbelt.com>
> Cc: alexandre.ghiti@canonical.com; linux-riscv@lists.infradead.org; linux-
> kernel@vger.kernel.org
> Subject: RE: arch/riscv: SV48 patch series questions
> 
> 
> 
> > -----Original Message-----
> > From: Palmer Dabbelt <palmer@dabbelt.com>
> > Sent: Thursday, 2 June, 2022 11:44 AM
> > To: Leyfoon Tan <leyfoon.tan@starfivetech.com>
> > Cc: alexandre.ghiti@canonical.com; linux-riscv@lists.infradead.org;
> > linux- kernel@vger.kernel.org
> > Subject: Re: arch/riscv: SV48 patch series questions
> >
> > On Fri, 27 May 2022 02:37:34 PDT (-0700), leyfoon.tan@starfivetech.com
> > wrote:
> > > Hi Palmer
> > >
> > > Alex's "Introduce sv48 support without relocatable kernel" patch
> > > series in
> > [1] was partially merged to Linux v5.17. But there are 4 patches are
> > not merged (Patch-10 to 13).
> > >
> > > May I know what is the plan for these patches? Will them merged to
> > > next
> > v5.19 merging window? Or do you expect any changes for these patches
> > or Alex needs resend with rebase to latest kernel version?
> >
> > I just saw this as I was digging up Alex's old email to reply to, all
> > but #13 are now on for-next.
> >
> > > Note, we would like to use the Patch-13 in this series.
> >
> > Is your use case a CPU errata?  If so I think we should just go ahead
> > and add that errata via the existing errata mechanism.  If you've got
> > some other use case, do you mind elaborating?  From that other thread
> > it sounds like a command-line argument is the way to go for folks who
> > want to turn this off more dynamically, but happy to hear if you've
> > got something different in mind.
> It is not CPU errata.
> RISC-V cpu can have sv39, sv48 or even sv57. If it is a heterogenous system,
> cpu cores in the system might have different sv. Eg: one cpu can be sv39 and
> another core is sv48.
> In this case, auto detection is not work. So, Patch-13 can help in this use case.
> 
> >
Hi Palmer

Any further comment for this?

Any chance merging Patch-13 in [1]?

[1] https://patchwork.kernel.org/project/linux-riscv/patch/20211206104657.433304-14-alexandre.ghiti@canonical.com/

Regards
Ley Foon