On Wed, May 19, 2021 at 05:04:13AM +0000, [email protected] wrote:
> From: Guo Ren <[email protected]>
>
> The RISC-V ISA doesn't yet specify how to query or modify PMAs, so let
> vendors define the custom properties of memory regions in PTE.
Err, hell no. The ISA needs to gets this fixed first. Then we can
talk about alternatives patching things in or trapping in the SBI.
But if the RISC-V ISA can't get these basic done after years we can't
support it in Linux at all.
On Wed, May 19, 2021 at 1:20 PM Christoph Hellwig <[email protected]> wrote:
>
> On Wed, May 19, 2021 at 05:04:13AM +0000, [email protected] wrote:
> > From: Guo Ren <[email protected]>
> >
> > The RISC-V ISA doesn't yet specify how to query or modify PMAs, so let
> > vendors define the custom properties of memory regions in PTE.
>
> Err, hell no. The ISA needs to gets this fixed first. Then we can
> talk about alternatives patching things in or trapping in the SBI.
> But if the RISC-V ISA can't get these basic done after years we can't
> support it in Linux at all.
The patchset just leaves a configuration chance for vendors. Before
RISC-V ISA fixes it, we should give the chance to let vendor solve
their real chip issues.
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
On Wed, May 19, 2021 at 1:20 PM Christoph Hellwig <[email protected]> wrote:
>
> On Wed, May 19, 2021 at 05:04:13AM +0000, [email protected] wrote:
> > From: Guo Ren <[email protected]>
> >
> > The RISC-V ISA doesn't yet specify how to query or modify PMAs, so let
> > vendors define the custom properties of memory regions in PTE.
>
> Err, hell no. The ISA needs to gets this fixed first. Then we can
> talk about alternatives patching things in or trapping in the SBI.
> But if the RISC-V ISA can't get these basic done after years we can't
> support it in Linux at all.
This is the lightest solution I could imagine, it avoids conflicts
with RISC-V ISA.
Since the existing RISC-V ISA cannot solve this problem, it is better
to provide some configuration for the SOC vendor to customize.
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
On Wed, May 19, 2021 at 02:05:00PM +0800, Guo Ren wrote:
> Since the existing RISC-V ISA cannot solve this problem, it is better
> to provide some configuration for the SOC vendor to customize.
We've been talking about this problem for close to five years. So no,
if you don't manage to get the feature into the ISA it can't be
supported.
On Wed, May 19, 2021 at 01:48:23PM +0800, Guo Ren wrote:
> On Wed, May 19, 2021 at 1:20 PM Christoph Hellwig <[email protected]> wrote:
> >
> > On Wed, May 19, 2021 at 05:04:13AM +0000, [email protected] wrote:
> > > From: Guo Ren <[email protected]>
> > >
> > > The RISC-V ISA doesn't yet specify how to query or modify PMAs, so let
> > > vendors define the custom properties of memory regions in PTE.
> >
> > Err, hell no. The ISA needs to gets this fixed first. Then we can
> > talk about alternatives patching things in or trapping in the SBI.
> > But if the RISC-V ISA can't get these basic done after years we can't
> > support it in Linux at all.
>
> The patchset just leaves a configuration chance for vendors. Before
> RISC-V ISA fixes it, we should give the chance to let vendor solve
> their real chip issues.
This patch series looks like it might be useful for the StarFive JH7100
[1] [2] too as it has peripherals on a non-coherent interconnect. GMAC,
USB and SDIO require that the L2 cache must be manually flushed after
DMA operations if the data is intended to be shared with U74 cores [2].
There is the RISC-V Cache Management Operation, or CMO, task group [3]
but I am not sure if that can help the SoC's that have already been
fabbed like the the D1 and the JH7100.
thanks,
drew
[1] https://github.com/starfive-tech/beaglev_doc/blob/main/JH7100%20Data%20Sheet%20V01.01.04-EN%20(4-21-2021).pdf
[2] https://github.com/starfive-tech/beaglev_doc/blob/main/JH7100%20Cache%20Coherence%20V1.0.pdf
[3] https://github.com/riscv/riscv-CMOs
On Wed, May 19, 2021 at 08:06:17AM +0200, Christoph Hellwig wrote:
> On Wed, May 19, 2021 at 02:05:00PM +0800, Guo Ren wrote:
> > Since the existing RISC-V ISA cannot solve this problem, it is better
> > to provide some configuration for the SOC vendor to customize.
>
> We've been talking about this problem for close to five years. So no,
> if you don't manage to get the feature into the ISA it can't be
> supported.
Isn't it a good goal for Linux to support the capabilities present in
the SoC that a currently being fab'd?
I believe the CMO group only started last year [1] so the RV64GC SoCs
that are going into mass production this year would not have had the
opporuntiy of utilizing any RISC-V ISA extension for handling cache
management.
Thanks,
Drew
[1] https://github.com/riscv/riscv-CMOs
On Tue, May 18, 2021 at 11:54:31PM -0700, Drew Fustini wrote:
> Isn't it a good goal for Linux to support the capabilities present in
> the SoC that a currently being fab'd?
>
> I believe the CMO group only started last year [1] so the RV64GC SoCs
> that are going into mass production this year would not have had the
> opporuntiy of utilizing any RISC-V ISA extension for handling cache
> management.
Then the vendors need to push harder. This problem has been known
for years but ignored by the vendors.