From: Palmer Dabbelt <palmer@sifive.com>
To: vincentc@andestech.com
Cc: zong@andestech.com, aou@eecs.berkeley.edu,
Arnd Bergmann <arnd@arndb.de>,
alankao@andestech.com, greentime@andestech.com,
linux-kernel@vger.kernel.org, vincentc@andestech.com,
kito@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: Tue, 06 Nov 2018 15:45:52 -0800 (PST) [thread overview]
Message-ID: <mhng-611cf294-d378-466f-83eb-6c114c70c585@palmer-si-x1c4> (raw)
Message-ID: <20181106234552.CpKcppI1_RlzTa3iOGLnnB7mftjoSBooinO3Rua73Ac@z> (raw)
In-Reply-To: <20181105065807.GA1286@andestech.com>
On Sun, 04 Nov 2018 22:58:07 PST (-0800), vincentc@andestech.com wrote:
> On Fri, Nov 02, 2018 at 01:48:57AM +0800, Karsten Merker wrote:
>> On Wed, Oct 31, 2018 at 10:27:05AM -0700, Palmer Dabbelt 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.
>>
>> From a distro point of view we definitely want to have one kernel
>> image that is bootable everywhere. Debian won't support any
>> platform that requires a per-platform or per-vendor kernel, and I
>> assume that the same will be true for Fedora and Suse.
>>
>> One thing that I have stumbled upon while looking at the patches
>> is that they seem to assume that X-type ISA extensions are
>> strictly per vendor. Although that is probably true in the
>> majority of cases, it doesn't necessarily have to be - I could
>> e.g. imagine that the DSP extensions from the PULP cores might
>> be used by multiple vendors. If such an extension would have
>> state that needs to be saved on context switch, it would need
>> corresponding kernel support. Using "PULP" (or any other
>> open-source project) as the vendor in such a case leads to
>> another potential issue: the patches base everything on a JEDEC
>> vendor ID that is compared to the contents of the mvendorid CSR,
>> but such a JEDEC vendor ID usually doesn't exist for open-source
>> implementations; the majority of those have mvendorid set to
>> zero.
>>
> Many thanks for kinds of comments. I quickly synthesize the comments and
> list them as below.
> 1. The kernel image shall include all vendor-specific code.
> 2. This kernel image can only enable particular vendor-specific features
> based on the CPU vendor in the running platform.
> - The runtime probing mechanism can refer to arm32/arm64, powerpc,
> IRQCHIP driver or CLOCKSOURCE driver
> - For some cases, such as open-source projects, using CSR $mvendorid
> to identify the compatibility is not appropriate.
> I think the above requirements are reasonable, but I have questions about
> the first requirement in practice. As far as I know, vendors are allowed
> to add specific instructions and CSRs which are incompatible with other
> vendors to their own ISA extensions. If I understand the first requirement
> correctly, it implies that we need a "super" RISC-V toolchain. This "super"
> RISC-V toolchain should recognize all kinds of vendor-specific instructions
> and CSRs, so that it can compile vendor sources into objects successfully;
> then it should recognize all kinds of vendor-specific relocations, so that
> it can link the objects successfully. Each of them is not trivial at the
> time of this proposal and in foreseeable future.
>
> If it will take a long time to complete this "super" toolchain, I suppose
> the infrastructure in this RFC might be a temporary solution before it is
> ready. This scheme does not suffer the compilation problems caused by the
> lack of the super toolchain because the selection of vendor-specific ISA
> extension is determined at compile time. In addition, the mechanism for
> checking compatibility at runtime ensures that the kernel with
> vendor-specific feature runs on CPUs of other vendors just like pure
> RISC-V kernel. In other words, this scheme, to some extent, satisfies the
> requirements that one kernel image is bootable everywhere.
I don't want anything in the kernel that can't be compiled by upstream GCC, as
that will be a huge mess. As far as I'm concerned, the best way to move
forward is to figure out how each style of extension can be integrated. Right
now, what I see is:
* Performance counters. Here we should be safe, as there's an ISA-mandated
space in which to put non-standard performance counters. The support here is
just figuring out how to interpret the bits. This naturally fits into our
current device-tree based mechanisms for probing hardware, and will be easy
to maintain in the kernel.
* Cache management. It appears these are currently being described as
instructions, which means they won't compile by default. Here I think the
best bet is to rely on the SBI, and if that's too slow to build a "SBI VDSO"
mechanism to accelerate the relevant bits. It is a bit of a headache, but
we're not going to have anything standardized here quickly.
If those are the only two concerns then I think we're OK. Are there any other
extension you're worried about?
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2018-11-06 23:46 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
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 [this message]
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=mhng-611cf294-d378-466f-83eb-6c114c70c585@palmer-si-x1c4 \
--to=palmer@sifive.com \
--cc=alankao@andestech.com \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@arndb.de \
--cc=deanbo422@gmail.com \
--cc=greentime@andestech.com \
--cc=kito@andestech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--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).