From: hch@infradead.org (Christoph Hellwig) To: linux-riscv@lists.infradead.org Subject: [RFC 0/2] RISC-V: A proposal to add vendor-specific code Date: Mon, 5 Nov 2018 22:59:11 -0800 [thread overview] Message-ID: <20181106065911.GB13526@infradead.org> (raw) In-Reply-To: <CAK8P3a2MSK-S+AzDGjq6t8WjcKrkj0XmynNL+fMPvL=JgnoEVA@mail.gmail.com> On Mon, Nov 05, 2018 at 02:51:33PM +0100, Arnd Bergmann wrote: > With the stricter policy you suggest, we'd loose the ability to support > some extensions that might be common: > > - an extension for user space that adds new registers that must be > saved and restored on a task switch, e.g. FPU, DSP or NPU > instructions. ARM supports several incompatible extensions like > that in one kernel, and this is really ugly, but I suspect RISC-V > will already need the same thing to support all combinations of > standard extensions, so from a practical perspective it's not > much different for custom extension, aside from the question > how far you want to go to discourage custom extensions by > requiring users to patch their kernels. Palmer already explain that this is supposed to be handled by the XS bit + SBI calls. I'm personally not totally sold on the SBI call and standard ways to save the state in the instruction set, similar to modern x86 might be a better option, but that is something the privileged spec working group will have to decide. > - A crypto instruction for a cipher that is used in the kernel > for speeding up network or block data encryption. > This would typically be a standalone loadable module, so > the impact of allowing custom extensions in addition to > standard ones is minimal. And that is a prime example for something that should never be vendor specific. If an instruction set extension is useful for something entirely generic it should be standardized in a working group as an extension.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org> To: Arnd Bergmann <arnd@arndb.de> Cc: zong@andestech.com, aou@eecs.berkeley.edu, alankao@andestech.com, greentime@andestech.com, palmer@sifive.com, linux-kernel@vger.kernel.org, Christoph Hellwig <hch@infradead.org>, Vincent Chen <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: Mon, 5 Nov 2018 22:59:11 -0800 [thread overview] Message-ID: <20181106065911.GB13526@infradead.org> (raw) Message-ID: <20181106065911.JKNOsII6a_Q5T0GLIKoNas_b9isYNlglknYkOSRtEz0@z> (raw) In-Reply-To: <CAK8P3a2MSK-S+AzDGjq6t8WjcKrkj0XmynNL+fMPvL=JgnoEVA@mail.gmail.com> On Mon, Nov 05, 2018 at 02:51:33PM +0100, Arnd Bergmann wrote: > With the stricter policy you suggest, we'd loose the ability to support > some extensions that might be common: > > - an extension for user space that adds new registers that must be > saved and restored on a task switch, e.g. FPU, DSP or NPU > instructions. ARM supports several incompatible extensions like > that in one kernel, and this is really ugly, but I suspect RISC-V > will already need the same thing to support all combinations of > standard extensions, so from a practical perspective it's not > much different for custom extension, aside from the question > how far you want to go to discourage custom extensions by > requiring users to patch their kernels. Palmer already explain that this is supposed to be handled by the XS bit + SBI calls. I'm personally not totally sold on the SBI call and standard ways to save the state in the instruction set, similar to modern x86 might be a better option, but that is something the privileged spec working group will have to decide. > - A crypto instruction for a cipher that is used in the kernel > for speeding up network or block data encryption. > This would typically be a standalone loadable module, so > the impact of allowing custom extensions in addition to > standard ones is minimal. And that is a prime example for something that should never be vendor specific. If an instruction set extension is useful for something entirely generic it should be standardized in a working group as an extension. _______________________________________________ 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 6:59 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 [this message] 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=20181106065911.GB13526@infradead.org \ --to=hch@infradead.org \ --cc=linux-riscv@lists.infradead.org \ /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: linkBe 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).