From: Palmer Dabbelt <palmerdabbelt@google.com>
To: guoren@kernel.org
Cc: anup@brainfault.org, drew@beagleboard.org,
Christoph Hellwig <hch@lst.de>, Anup Patel <Anup.Patel@wdc.com>,
wefu@redhat.com, lazyparser@gmail.com,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, linux-sunxi@lists.linux.dev,
guoren@linux.alibaba.com,
Paul Walmsley <paul.walmsley@sifive.com>
Subject: Re: [PATCH RFC 0/3] riscv: Add DMA_COHERENT support
Date: Sat, 29 May 2021 17:30:18 -0700 (PDT) [thread overview]
Message-ID: <mhng-a5f8374f-350b-4c13-86e8-c6aa5e697454@palmerdabbelt-glaptop> (raw)
In-Reply-To: <CAJF2gTTBAKTBY5AF9jd8tfT-33Y+McyFis_xk_aMvZZpLsvVxw@mail.gmail.com>
On Fri, 21 May 2021 17:36:08 PDT (-0700), guoren@kernel.org wrote:
> On Wed, May 19, 2021 at 3:15 PM Anup Patel <anup@brainfault.org> wrote:
>>
>> On Wed, May 19, 2021 at 12:24 PM Drew Fustini <drew@beagleboard.org> wrote:
>> >
>> > 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.
>>
>> The current Linux RISC-V policy is to only accept patches for frozen or
>> ratified ISA specs.
>> (Refer, Documentation/riscv/patch-acceptance.rst)
>>
>> This means even if emulate CMO instructions in OpenSBI, the Linux
>> patches won't be taken by Palmer because CMO specification is
>> still in draft stage.
> Before CMO specification release, could we use a sbi_ecall to solve
> the current problem? This is not against the specification, when CMO
> is ready we could let users choose to use the new CMO in Linux.
>
> From a tech view, CMO trap emulation is the same as sbi_ecall.
>
>>
>> Also, we all know how much time it takes for RISCV international
>> to freeze some spec. Judging by that we are looking at another
>> 3-4 years at minimum.
Sorry for being slow here, this thread got buried.
I've been trying to work with a handful of folks at the RISC-V
foundation to try and get a subset of the various in-development
specifications (some simple CMOs, something about non-caching in the
page tables, and some way to prevent speculative accesse from generating
coherence traffic that will break non-coherent systems). I'm not sure
we can get this together quickly, but I'd prefer to at least try before
we jump to taking vendor-specificed behavior here. It's obviously an
up-hill battle to try and get specifications through the process and I'm
certainly not going to promise it will work, but I'm hoping that the
impending need to avoid forking the ISA will be sufficient to get people
behind producing some specifications in a timely fashion.
I wasn't aware than this chip had non-coherent devices until I saw this
thread, so we'd been mostly focused on the Beagle V chip. That was in a
sense an easier problem because the SiFive IP in it was never designed
to have non-coherent devices so we'd have to make anything work via a
series of slow workarounds, which would make emulating the eventually
standardized behavior reasonable in terms of performance (ie, everything
would be super slow so who really cares).
I don't think relying on some sort of SBI call for the CMOs whould be
such a performance hit that it would prevent these systems from being
viable, but assuming you have reasonable performance on your non-cached
accesses then that's probably not going to be viable to trap and
emulate. At that point it really just becomes silly to pretend that
we're still making things work by emulating the eventually ratified
behavior, as anyone who actually tries to use this thing to do IO would
need out of tree patches. I'm not sure exactly what the plan is for the
page table bits in the specification right now, but if you can give me a
pointer to some documentation then I'm happy to try and push for
something compatible.
If we can't make the process work at the foundation then I'd be strongly
in favor of just biting the bullet and starting to take vendor-specific
code that's been implemented in hardware and is necessarry to make
things work acceptably. That's obviously a sub-optimal solution as
it'll lead to a bunch of ISA fragmentation, but at least we'll be able
to keep the software stack together.
Can you tell us when these will be in the hands of users? That's pretty
important here, as I don't want to be blocking real users from having
their hardware work. IIRC there were some plans to distribute early
boards, but it looks like the foundation got involved and I guess I lost
the thread at that point.
Sorry this is all such a headache, but hopefully we can get things
sorted out.
>>
>> Regards,
>> Anup
next prev parent reply other threads:[~2021-05-30 0:30 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-19 5:04 [PATCH RFC 0/3] riscv: Add DMA_COHERENT support guoren
2021-05-19 5:04 ` [PATCH RFC 1/3] riscv: pgtable.h: Fixup _PAGE_CHG_MASK usage guoren
2021-05-19 5:04 ` [PATCH RFC 2/3] riscv: Add DMA_COHERENT for custom PTE attributes guoren
2021-05-19 5:04 ` [PATCH RFC 3/3] riscv: Add SYNC_DMA_FOR_CPU/DEVICE for DMA_COHERENT guoren
2021-05-19 6:32 ` Guo Ren
2021-05-19 5:20 ` [PATCH RFC 0/3] riscv: Add DMA_COHERENT support Christoph Hellwig
2021-05-19 5:48 ` Guo Ren
2021-05-19 5:55 ` Christoph Hellwig
2021-05-19 6:09 ` Guo Ren
2021-05-19 6:44 ` Drew Fustini
2021-05-19 6:53 ` Christoph Hellwig
2021-05-20 1:45 ` Guo Ren
2021-05-20 5:48 ` Christoph Hellwig
2021-06-06 18:14 ` Nick Kossifidis
2021-06-07 0:04 ` Guo Ren
2021-06-07 2:16 ` Nick Kossifidis
2021-06-07 3:19 ` Guo Ren
2021-06-07 6:27 ` Christoph Hellwig
2021-06-07 6:41 ` Guo Ren
2021-06-07 6:51 ` Christoph Hellwig
2021-06-07 7:46 ` Guo Ren
2021-06-08 15:00 ` David Laight
2021-06-08 15:32 ` 'Christoph Hellwig'
2021-06-08 16:11 ` David Laight
2021-06-07 8:35 ` Nick Kossifidis
2021-06-09 3:28 ` Guo Ren
2021-06-09 6:05 ` Jisheng Zhang
2021-06-09 9:45 ` Nick Kossifidis
2021-06-09 12:43 ` Guo Ren
2021-05-19 6:05 ` Guo Ren
2021-05-19 6:06 ` Christoph Hellwig
2021-05-19 6:11 ` Guo Ren
2021-05-19 6:54 ` Drew Fustini
2021-05-19 6:56 ` Christoph Hellwig
2021-05-19 7:14 ` Anup Patel
2021-05-19 8:25 ` Damien Le Moal
2021-05-20 1:47 ` Guo Ren
2021-05-20 1:59 ` Guo Ren
2021-05-22 0:36 ` Guo Ren
2021-05-30 0:30 ` Palmer Dabbelt [this message]
2021-06-03 4:13 ` Palmer Dabbelt
2021-06-03 6:00 ` Anup Patel
2021-06-03 15:39 ` Palmer Dabbelt
2021-06-04 9:02 ` David Laight
2021-06-04 9:53 ` Arnd Bergmann
2021-06-04 14:47 ` Guo Ren
2021-06-04 16:12 ` Palmer Dabbelt
2021-06-04 21:26 ` Arnd Bergmann
2021-06-04 22:10 ` Palmer Dabbelt
2021-06-08 12:26 ` Guo Ren
2021-06-06 17:11 ` Guo Ren
2021-06-07 3:38 ` Anup Patel
2021-06-07 4:22 ` Guo Ren
2021-06-07 4:47 ` Anup Patel
2021-06-07 5:08 ` Guo Ren
2021-06-07 5:13 ` Guo Ren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mhng-a5f8374f-350b-4c13-86e8-c6aa5e697454@palmerdabbelt-glaptop \
--to=palmerdabbelt@google.com \
--cc=Anup.Patel@wdc.com \
--cc=anup@brainfault.org \
--cc=drew@beagleboard.org \
--cc=guoren@kernel.org \
--cc=guoren@linux.alibaba.com \
--cc=hch@lst.de \
--cc=lazyparser@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=paul.walmsley@sifive.com \
--cc=wefu@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).