From: Olof Johansson <olof@lixom.net>
To: Palmer Dabbelt <palmer@sifive.com>
Cc: zong@andestech.com, Albert Ou <aou@eecs.berkeley.edu>,
Arnd Bergmann <arnd@arndb.de>,
alankao@andestech.com, greentime@andestech.com,
anup@brainfault.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
vincentc@andestech.com, linux-riscv@lists.infradead.org,
deanbo422@gmail.com
Subject: Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
Date: Wed, 31 Oct 2018 12:17:32 -0700 [thread overview]
Message-ID: <CAOesGMjHTRqqUWB9=XQADPxA+EWwcOSBrFsJB7c4m2b9kBAOmQ@mail.gmail.com> (raw)
Message-ID: <20181031191732.uL3akoJqLvIDO_3yEwG7RQmeEvgnHmYATj8LMPa1rfg@z> (raw)
In-Reply-To: <mhng-01f0ac6a-c2fd-41be-9d53-44d1c139d453@palmer-si-x1c4>
On Wed, Oct 31, 2018 at 10:27 AM Palmer Dabbelt <palmer@sifive.com> wrote:
>
> On Wed, 31 Oct 2018 04:16:10 PDT (-0700), anup@brainfault.org wrote:
> > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen <vincentc@andestech.com> wrote:
> >>
> >> RISC-V permits each vendor to develop respective extension ISA based
> >> on RISC-V standard ISA. This means that these vendor-specific features
> >> may be compatible to their compiler and CPU. Therefore, each vendor may
> >> be considered a sub-architecture of RISC-V. Currently, vendors do not
> >> have the appropriate examples to add these specific features to the
> >> kernel. In this RFC set, we propose an infrastructure that vendor can
> >> easily hook their specific features into kernel. The first commit is
> >> the main body of this infrastructure. In the second commit, we provide
> >> a solution that allows dma_map_ops() to work without cache coherent
> >> agent support. Cache coherent agent is unsupported for low-end CPUs in
> >> the AndeStar RISC-V series. In order for Linux to run on these CPUs, we
> >> need this solution to overcome the limitation of cache coherent agent
> >> support. Hence, it also can be used as an example for the first commit.
> >>
> >> I am glad to discuss any ideas, so if you have any idea, please give
> >> me some feedback.
> >>
> >
> > I agree that we need a place for vendor-specific ISA extensions and
> > having vendor-specific directories is also good.
> >
> > What I don't support is the approach of having compile time selection
> > of vendor-specific ISA extension.
> >
> > We should have runtime probing for compatible vendor-specific ISA
> > extension. Also, it should be possible to link multiple vendor-specific
> > SA extensions to same kernel image. This way we can have a single
> > kernel image (along with various vendor-specific ISA extensions) which
> > works on variety of targets/hosts.
> >
> > As an example or runtime probing you can look at how IRQCHIP or
> > CLOCKSOURCE drivers are probed. The vendor-specific ISA extension
> > hooks should called in similar fashion.
>
> Yes, I agree. My biggest concern here is that we ensure that one kernel can
> boot on implementations from all vendors. I haven't had a chance to look at
> the patches yet, but it should be possible to:
>
> * Build a kernel that has vendor-specific code from multiple vendors.
> * Detect the implementation an run time and select the correct extra code.
>
> This is essentially the same as my feedback for the performance counter stuff,
> which IIRC is what prompted adding a vendor-specific extensions.
>
> If I was going to do this, I'd split it up such that the vendor-specific
> additions are per-subsystem. That way we can focus on building a decent
> interface for each subsystem that needs vendor-specific support rather than
> just bundling everything together where the vendor-specific stuff will get all
> tangled together.
For short-term, powerpc's model of a machine descriptor with function
pointers that's either filled in at runtime, or set to the right
pre-defined structure per platform, should cover most of this I think?
Even if you have cases where an indirect branch isn't feasible,
performance-wise, _getting_ the function address from the table and
doing runtime alternatives-style patching still gives one place to
keep it.
I'm not sure if we need a table/struct per subsystem, or if one larger
shared one is sufficient to start. Since this is all in-kernel code
without external interface, I'd suggest starting simple and refactor
later if needed.
-Olof
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2018-10-31 19:18 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-31 10:35 [RFC 0/2] RISC-V: A proposal to add vendor-specific code Vincent Chen
2018-10-31 10:35 ` Vincent Chen
2018-10-31 10:35 ` [RFC 1/2] RISC-V: An infrastructure " Vincent Chen
2018-10-31 10:35 ` Vincent Chen
2018-10-31 10:35 ` [RFC 2/2] RISC-V: make dma_map_ops work without cache coherent agent Vincent Chen
2018-10-31 10:35 ` Vincent Chen
2018-10-31 11:16 ` [RFC 0/2] RISC-V: A proposal to add vendor-specific code Anup Patel
2018-10-31 11:16 ` Anup Patel
2018-10-31 11:45 ` Arnd Bergmann
2018-10-31 11:45 ` Arnd Bergmann
2018-10-31 14:17 ` Christoph Hellwig
2018-10-31 14:17 ` Christoph Hellwig
2018-11-01 0:55 ` Alan Kao
2018-11-01 0:55 ` Alan Kao
2018-11-01 17:50 ` Palmer Dabbelt
2018-11-01 17:50 ` Palmer Dabbelt
2018-11-02 0:41 ` Alan Kao
2018-11-02 0:41 ` Alan Kao
2018-10-31 17:27 ` Palmer Dabbelt
2018-10-31 17:27 ` Palmer Dabbelt
2018-10-31 19:17 ` Olof Johansson [this message]
2018-10-31 19:17 ` Olof Johansson
2018-11-01 17:48 ` Karsten Merker
2018-11-05 6:58 ` Vincent Chen
2018-11-05 6:58 ` Vincent Chen
2018-11-05 7:05 ` Christoph Hellwig
2018-11-05 7:05 ` Christoph Hellwig
2018-11-05 8:52 ` Arnd Bergmann
2018-11-05 8:52 ` Arnd Bergmann
2018-11-05 9:08 ` Christoph Hellwig
2018-11-05 9:08 ` Christoph Hellwig
2018-11-05 13:51 ` Arnd Bergmann
2018-11-05 13:51 ` Arnd Bergmann
2018-11-06 6:59 ` Christoph Hellwig
2018-11-06 6:59 ` Christoph Hellwig
2018-11-06 23:45 ` Palmer Dabbelt
2018-11-06 23:45 ` Palmer Dabbelt
2018-11-07 9:51 ` Arnd Bergmann
2018-11-07 9:51 ` Arnd Bergmann
2018-11-06 23:45 ` Palmer Dabbelt
2018-11-06 23:45 ` Palmer Dabbelt
2018-11-08 2:43 ` Vincent Chen
2018-11-08 2:43 ` Vincent Chen
2018-11-05 19:39 ` Nick Kossifidis
2018-11-05 19:39 ` Nick Kossifidis
2018-11-06 6:56 ` Christoph Hellwig
2018-11-06 6:56 ` Christoph Hellwig
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='CAOesGMjHTRqqUWB9=XQADPxA+EWwcOSBrFsJB7c4m2b9kBAOmQ@mail.gmail.com' \
--to=olof@lixom.net \
--cc=alankao@andestech.com \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@arndb.de \
--cc=deanbo422@gmail.com \
--cc=greentime@andestech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@sifive.com \
--cc=vincentc@andestech.com \
--cc=zong@andestech.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).