2022-05-28 19:35:42

by Leyfoon Tan

[permalink] [raw]
Subject: arch/riscv: SV48 patch series questions

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/[email protected]/

Thanks.

Regards
Ley Foon


2022-06-02 04:27:44

by Palmer Dabbelt

[permalink] [raw]
Subject: Re: arch/riscv: SV48 patch series questions

On Fri, 27 May 2022 02:37:34 PDT (-0700), [email protected] 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/[email protected]/
>
> Thanks.
>
> Regards
> Ley Foon

2022-06-02 08:04:35

by Leyfoon Tan

[permalink] [raw]
Subject: RE: arch/riscv: SV48 patch series questions



> -----Original Message-----
> From: Palmer Dabbelt <[email protected]>
> Sent: Thursday, 2 June, 2022 11:44 AM
> To: Leyfoon Tan <[email protected]>
> Cc: [email protected]; [email protected]; linux-
> [email protected]
> Subject: Re: arch/riscv: SV48 patch series questions
>
> On Fri, 27 May 2022 02:37:34 PDT (-0700), [email protected]
> 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.
> > [email protected]/
> >

Thanks.

Regards
Ley Foon

2022-07-01 02:37:03

by Leyfoon Tan

[permalink] [raw]
Subject: RE: arch/riscv: SV48 patch series questions



> -----Original Message-----
> From: Leyfoon Tan
> Sent: Thursday, 2 June, 2022 1:44 PM
> To: 'Palmer Dabbelt' <[email protected]>
> Cc: [email protected]; [email protected]; linux-
> [email protected]
> Subject: RE: arch/riscv: SV48 patch series questions
>
>
>
> > -----Original Message-----
> > From: Palmer Dabbelt <[email protected]>
> > Sent: Thursday, 2 June, 2022 11:44 AM
> > To: Leyfoon Tan <[email protected]>
> > Cc: [email protected]; [email protected];
> > linux- [email protected]
> > Subject: Re: arch/riscv: SV48 patch series questions
> >
> > On Fri, 27 May 2022 02:37:34 PDT (-0700), [email protected]
> > 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/[email protected]/

Regards
Ley Foon