Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, Nov 07, 2018 at 07:45:52AM +0800, Palmer Dabbelt wrote: > On Sun, 04 Nov 2018 22:58:07 PST (-0800), vince...@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), a...@brainfault.org wrote: > >> > > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen > >> > > 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 >
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, Nov 07, 2018 at 07:45:52AM +0800, Palmer Dabbelt wrote: > On Sun, 04 Nov 2018 22:58:07 PST (-0800), vince...@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), a...@brainfault.org wrote: > >> > > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen > >> > > 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 >
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On 11/7/18, Palmer Dabbelt wrote: > On Mon, 05 Nov 2018 00:52:52 PST (-0800), Arnd Bergmann wrote: >> On 11/5/18, Christoph Hellwig wrote: >>> On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote: 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. >>> >>> I fundamentally disagree with this… and think it should be the contrary. >>> >>> 1. The kernel shall support no vendor specific instructions whatsoever, >>> period. >> >> I think what was meant above is >> >> 1. If a vendor extension requires kernel support, that support >> must be able to be built into a kernel image without breaking support >> for CPUs that do not have that extension, to allow building a single >> kernel image that works on all CPUs. > > Yes. I don't want anything that won't compile with upstream GCC, but I also > > don't want to have a Kconfig that says "make the kernel only work on > $VENDOR's implementation". I think this can be achieved, at least for the > cases I've seen so far. I think over time, the implementations will diverge. Ignoring the question of vendor extensions for the moment, you will definitely have to deal with combinations of (future) standard extensions. I can see two ways of doing that: Either each extension is a separate Kconfig option and you have to know which one to enable or disable for a particular target, or you list each platform separately with one Kconfig option, and have Kconfig/Kbuild work out which features to enable or disable based on that to get the fastest and most featureful kernel that still works on all enabled platforms. Arnd
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On 11/7/18, Palmer Dabbelt wrote: > On Mon, 05 Nov 2018 00:52:52 PST (-0800), Arnd Bergmann wrote: >> On 11/5/18, Christoph Hellwig wrote: >>> On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote: 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. >>> >>> I fundamentally disagree with this… and think it should be the contrary. >>> >>> 1. The kernel shall support no vendor specific instructions whatsoever, >>> period. >> >> I think what was meant above is >> >> 1. If a vendor extension requires kernel support, that support >> must be able to be built into a kernel image without breaking support >> for CPUs that do not have that extension, to allow building a single >> kernel image that works on all CPUs. > > Yes. I don't want anything that won't compile with upstream GCC, but I also > > don't want to have a Kconfig that says "make the kernel only work on > $VENDOR's implementation". I think this can be achieved, at least for the > cases I've seen so far. I think over time, the implementations will diverge. Ignoring the question of vendor extensions for the moment, you will definitely have to deal with combinations of (future) standard extensions. I can see two ways of doing that: Either each extension is a separate Kconfig option and you have to know which one to enable or disable for a particular target, or you list each platform separately with one Kconfig option, and have Kconfig/Kbuild work out which features to enable or disable based on that to get the fastest and most featureful kernel that still works on all enabled platforms. Arnd
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Mon, 05 Nov 2018 00:52:52 PST (-0800), Arnd Bergmann wrote: On 11/5/18, Christoph Hellwig wrote: On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote: 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. I fundamentally disagree with this… and think it should be the contrary. 1. The kernel shall support no vendor specific instructions whatsoever, period. I think what was meant above is 1. If a vendor extension requires kernel support, that support must be able to be built into a kernel image without breaking support for CPUs that do not have that extension, to allow building a single kernel image that works on all CPUs. Yes. I don't want anything that won't compile with upstream GCC, but I also don't want to have a Kconfig that says "make the kernel only work on $VENDOR's implementation". I think this can be achieved, at least for the cases I've seen so far.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Sun, 04 Nov 2018 22:58:07 PST (-0800), vince...@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), a...@brainfault.org wrote: > > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen 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
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Mon, 05 Nov 2018 00:52:52 PST (-0800), Arnd Bergmann wrote: On 11/5/18, Christoph Hellwig wrote: On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote: 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. I fundamentally disagree with this… and think it should be the contrary. 1. The kernel shall support no vendor specific instructions whatsoever, period. I think what was meant above is 1. If a vendor extension requires kernel support, that support must be able to be built into a kernel image without breaking support for CPUs that do not have that extension, to allow building a single kernel image that works on all CPUs. Yes. I don't want anything that won't compile with upstream GCC, but I also don't want to have a Kconfig that says "make the kernel only work on $VENDOR's implementation". I think this can be achieved, at least for the cases I've seen so far.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Sun, 04 Nov 2018 22:58:07 PST (-0800), vince...@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), a...@brainfault.org wrote: > > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen 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
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
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.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
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.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Mon, Nov 05, 2018 at 09:39:29PM +0200, Nick Kossifidis wrote: > a) By directly modifying your custom CSRs, it means that we will need > compiler support in order to compile a kernel with your code in it. This > will break CI systems and will introduce various issues on testing and > reviewing your code. In general if we need custom toolchains to compile > the kernel, that may be unavailable (vendors will not always open source > their compiler support), we won't be able to maintain a decent level of > code quality in the tree. How can the maintainer push your code on the > repository if he/she can't even perform a basic compilation test ? And that (besides avoiding the wild growth of extensions) is the major reason why accepting vendor specific CSRs or instructions is a no-go.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Mon, Nov 05, 2018 at 09:39:29PM +0200, Nick Kossifidis wrote: > a) By directly modifying your custom CSRs, it means that we will need > compiler support in order to compile a kernel with your code in it. This > will break CI systems and will introduce various issues on testing and > reviewing your code. In general if we need custom toolchains to compile > the kernel, that may be unavailable (vendors will not always open source > their compiler support), we won't be able to maintain a decent level of > code quality in the tree. How can the maintainer push your code on the > repository if he/she can't even perform a basic compilation test ? And that (besides avoiding the wild growth of extensions) is the major reason why accepting vendor specific CSRs or instructions is a no-go.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
Hello Vincent, Στις 2018-10-31 12:35, Vincent Chen έγραψε: 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. So if I got this right, in your case you've added some CSRs (ucctlbeginaddr and ucctlcommand) for marking regions as non-cacheable, and you provide your own get_arch_dma_ops by overriding the default header files with your vendor-specific ones. Some things that are IMHO wrong with the proposed approach: a) By directly modifying your custom CSRs, it means that we will need compiler support in order to compile a kernel with your code in it. This will break CI systems and will introduce various issues on testing and reviewing your code. In general if we need custom toolchains to compile the kernel, that may be unavailable (vendors will not always open source their compiler support), we won't be able to maintain a decent level of code quality in the tree. How can the maintainer push your code on the repository if he/she can't even perform a basic compilation test ? In contrast with ARM and others that have a standard set of possible extensions (e.g. NEON, crc32 etc), and provide compiler support for those, a similar approach is not valid for RISC-V. We could demand that vendors add compiler support e.g. on gcc before submitting a patch with custom assembly but I don't think this approach is feasible (one vendor's CSRs or custom instructions may overlap with another's). I believe we should just use SBI calls instead and let the firmware (and/or custom userspace libraries) handle the custom CSRs/assembly instructions. This is a concern also for lib/ and crypto/ where vendors might want to use their own extensions for providing optimized assembly for their cores. It's not a big deal to use SBI and handle vendor-specific stuff on firmware and/or userspace, it's actually more flexible for the vendors since they can have their own process for maintaining their firmware and releasing it in their own terms/license etc. If we see that the SBI has too much overhead or is not enough we can design it in a better way or extend it. It will still be standard and easier to maintain than a fragmented ecosystem of mostly unusable code, inside the mainline kernel. In case we need to save/store registers related to a custom extension, I guess we can also have an SBI call for saving/restoring custom registers to/from S-managed memory and we should be ok. It should also be possible to do any extra state handling in firmware if needed. I believe we can and should avoid custom assembly on the kernel at all costs ! b) By using CONFIG_VENDOR_FOLDER_NAME you add a compile time dependency that allows this kernel image to be built for a specific vendor. This is problematic in different ways. At first it's not possible to have a kernel image that's generic and can be used for all RISC-V systems. That's what distros want and that's how they 've been working so far. Also in case a vendor has many different boards with different implementation details how will this approach help ? It would make more sense to have something like arch/riscv/. Also have in mind that some extensions might be available as IP to vendors so multiple vendors might use the same extension made/licensed from another vendor. I think arch/riscv/ is more appropriate. Since we can use mvendorid/marchid/mimpid to identify that at runtime maybe we can have some wrapper code that initializes a struct of function pointers early on setup_arch(), allowing vendors to populate it according to the available extensions in their hw, based on the above ids. We can also just use device-tree for that and mark the used extensions there. We can even pass extension-specific parameters this way (e.g. to save CSRs) in case of extensions that can be parametrized on hw design phase (I'm thinking of IPs sold from companies with licenses for unlocking the X feature or for supporting up to Y channels/slots/instances/whatever). In any case it's an interesting subject that we definitely need to think about,
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
Hello Vincent, Στις 2018-10-31 12:35, Vincent Chen έγραψε: 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. So if I got this right, in your case you've added some CSRs (ucctlbeginaddr and ucctlcommand) for marking regions as non-cacheable, and you provide your own get_arch_dma_ops by overriding the default header files with your vendor-specific ones. Some things that are IMHO wrong with the proposed approach: a) By directly modifying your custom CSRs, it means that we will need compiler support in order to compile a kernel with your code in it. This will break CI systems and will introduce various issues on testing and reviewing your code. In general if we need custom toolchains to compile the kernel, that may be unavailable (vendors will not always open source their compiler support), we won't be able to maintain a decent level of code quality in the tree. How can the maintainer push your code on the repository if he/she can't even perform a basic compilation test ? In contrast with ARM and others that have a standard set of possible extensions (e.g. NEON, crc32 etc), and provide compiler support for those, a similar approach is not valid for RISC-V. We could demand that vendors add compiler support e.g. on gcc before submitting a patch with custom assembly but I don't think this approach is feasible (one vendor's CSRs or custom instructions may overlap with another's). I believe we should just use SBI calls instead and let the firmware (and/or custom userspace libraries) handle the custom CSRs/assembly instructions. This is a concern also for lib/ and crypto/ where vendors might want to use their own extensions for providing optimized assembly for their cores. It's not a big deal to use SBI and handle vendor-specific stuff on firmware and/or userspace, it's actually more flexible for the vendors since they can have their own process for maintaining their firmware and releasing it in their own terms/license etc. If we see that the SBI has too much overhead or is not enough we can design it in a better way or extend it. It will still be standard and easier to maintain than a fragmented ecosystem of mostly unusable code, inside the mainline kernel. In case we need to save/store registers related to a custom extension, I guess we can also have an SBI call for saving/restoring custom registers to/from S-managed memory and we should be ok. It should also be possible to do any extra state handling in firmware if needed. I believe we can and should avoid custom assembly on the kernel at all costs ! b) By using CONFIG_VENDOR_FOLDER_NAME you add a compile time dependency that allows this kernel image to be built for a specific vendor. This is problematic in different ways. At first it's not possible to have a kernel image that's generic and can be used for all RISC-V systems. That's what distros want and that's how they 've been working so far. Also in case a vendor has many different boards with different implementation details how will this approach help ? It would make more sense to have something like arch/riscv/. Also have in mind that some extensions might be available as IP to vendors so multiple vendors might use the same extension made/licensed from another vendor. I think arch/riscv/ is more appropriate. Since we can use mvendorid/marchid/mimpid to identify that at runtime maybe we can have some wrapper code that initializes a struct of function pointers early on setup_arch(), allowing vendors to populate it according to the available extensions in their hw, based on the above ids. We can also just use device-tree for that and mark the used extensions there. We can even pass extension-specific parameters this way (e.g. to save CSRs) in case of extensions that can be parametrized on hw design phase (I'm thinking of IPs sold from companies with licenses for unlocking the X feature or for supporting up to Y channels/slots/instances/whatever). In any case it's an interesting subject that we definitely need to think about,
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On 11/5/18, Christoph Hellwig wrote: > On Mon, Nov 05, 2018 at 09:52:52AM +0100, Arnd Bergmann wrote: >> > I fundamentally disagree with this… and think it should be the >> > contrary. >> > >> > 1. The kernel shall support no vendor specific instructions whatsoever, >> > period. >> >> I think what was meant above is >> >> 1. If a vendor extension requires kernel support, that support >> must be able to be built into a kernel image without breaking support >> for CPUs that do not have that extension, to allow building a single >> kernel image that works on all CPUs. > > No. This literally means no vendor extensions involving instructions > or CSRs in the kernel. They are fine for userspace, or for the M-mode > code including impementation of the SBI, but not for the kernel. I was trying to interpret what Vincent wrote, not what you wrote, you were pretty clear already ;-) 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. - 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. Arnd
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On 11/5/18, Christoph Hellwig wrote: > On Mon, Nov 05, 2018 at 09:52:52AM +0100, Arnd Bergmann wrote: >> > I fundamentally disagree with this… and think it should be the >> > contrary. >> > >> > 1. The kernel shall support no vendor specific instructions whatsoever, >> > period. >> >> I think what was meant above is >> >> 1. If a vendor extension requires kernel support, that support >> must be able to be built into a kernel image without breaking support >> for CPUs that do not have that extension, to allow building a single >> kernel image that works on all CPUs. > > No. This literally means no vendor extensions involving instructions > or CSRs in the kernel. They are fine for userspace, or for the M-mode > code including impementation of the SBI, but not for the kernel. I was trying to interpret what Vincent wrote, not what you wrote, you were pretty clear already ;-) 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. - 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. Arnd
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Mon, Nov 05, 2018 at 09:52:52AM +0100, Arnd Bergmann wrote: > > I fundamentally disagree with this… and think it should be the contrary. > > > > 1. The kernel shall support no vendor specific instructions whatsoever, > > period. > > I think what was meant above is > > 1. If a vendor extension requires kernel support, that support > must be able to be built into a kernel image without breaking support > for CPUs that do not have that extension, to allow building a single > kernel image that works on all CPUs. No. This literally means no vendor extensions involving instructions or CSRs in the kernel. They are fine for userspace, or for the M-mode code including impementation of the SBI, but not for the kernel.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Mon, Nov 05, 2018 at 09:52:52AM +0100, Arnd Bergmann wrote: > > I fundamentally disagree with this… and think it should be the contrary. > > > > 1. The kernel shall support no vendor specific instructions whatsoever, > > period. > > I think what was meant above is > > 1. If a vendor extension requires kernel support, that support > must be able to be built into a kernel image without breaking support > for CPUs that do not have that extension, to allow building a single > kernel image that works on all CPUs. No. This literally means no vendor extensions involving instructions or CSRs in the kernel. They are fine for userspace, or for the M-mode code including impementation of the SBI, but not for the kernel.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On 11/5/18, Christoph Hellwig wrote: > On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote: >> 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. > > I fundamentally disagree with this… and think it should be the contrary. > > 1. The kernel shall support no vendor specific instructions whatsoever, > period. I think what was meant above is 1. If a vendor extension requires kernel support, that support must be able to be built into a kernel image without breaking support for CPUs that do not have that extension, to allow building a single kernel image that works on all CPUs. Arnd
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On 11/5/18, Christoph Hellwig wrote: > On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote: >> 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. > > I fundamentally disagree with this… and think it should be the contrary. > > 1. The kernel shall support no vendor specific instructions whatsoever, > period. I think what was meant above is 1. If a vendor extension requires kernel support, that support must be able to be built into a kernel image without breaking support for CPUs that do not have that extension, to allow building a single kernel image that works on all CPUs. Arnd
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote: > 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. I fundamentally disagree with this… and think it should be the contrary. 1. The kernel shall support no vendor specific instructions whatsoever, period.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Mon, Nov 05, 2018 at 02:58:07PM +0800, Vincent Chen wrote: > 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. I fundamentally disagree with this… and think it should be the contrary. 1. The kernel shall support no vendor specific instructions whatsoever, period.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
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), a...@brainfault.org wrote: > > > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen > > > 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"
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
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), a...@brainfault.org wrote: > > > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen > > > 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"
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Thu, Nov 01, 2018 at 10:50:04AM -0700, Palmer Dabbelt wrote: > On Wed, 31 Oct 2018 17:55:42 PDT (-0700), alan...@andestech.com wrote: > >On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote: > >>On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote: > >>> I agree that we need a place for vendor-specific ISA extensions and > >>> having vendor-specific directories is also good. > >> > >>The only sensible answer is that we should not allow vendor specific > >>extensions in the kernel at all. ... > > > >How can this even be possible if a extension includes an extra register > >set as some domain-specific context? In such a case, kernel should > >at least process the context during any context switch, just like how it > >deals with the FP context. > > Ya, I think there are cases where vendor-specific extensions are going to be > necessary to handle within the kernel. Right now the only one I can think > of is the performance counter stuff, where we explicitly allow > vendor-specific counters as part of the ISA spec. > > For stateful extensions, we currently have a standard mechanism where the XS > bits get set in sstatus and the actual save/restore code is hidden behind an > SBI call. That call doesn't currently exist, but if we just go ahead and > add one it should be easy to support this from within Linux. We'll need to > figure out how to enable these custom extensions from userspace, but that > seems tractable as well. We'll probably also want some fast-path for the V > extension (and any other stateful standard extensions), but I think as long > as the V extension adds a quick check for dirtiness then it's not a big > deal. > > Do you guys have stateful extensions? We're trying really hard to avoid > them at SiFive because they're a huge headache, so unless there's a > compelling base of software using one I don't want to go add support if we > can avoid it. Currently no, but the future is hard to see. As long as the extensible freedom claimed by the RISC-V foundation remains true, such extensions may have their role to play. Don't worry now, I was just to give a example that in some possible vendor-specific cases the kernel cannot keep itself from involving.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Thu, Nov 01, 2018 at 10:50:04AM -0700, Palmer Dabbelt wrote: > On Wed, 31 Oct 2018 17:55:42 PDT (-0700), alan...@andestech.com wrote: > >On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote: > >>On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote: > >>> I agree that we need a place for vendor-specific ISA extensions and > >>> having vendor-specific directories is also good. > >> > >>The only sensible answer is that we should not allow vendor specific > >>extensions in the kernel at all. ... > > > >How can this even be possible if a extension includes an extra register > >set as some domain-specific context? In such a case, kernel should > >at least process the context during any context switch, just like how it > >deals with the FP context. > > Ya, I think there are cases where vendor-specific extensions are going to be > necessary to handle within the kernel. Right now the only one I can think > of is the performance counter stuff, where we explicitly allow > vendor-specific counters as part of the ISA spec. > > For stateful extensions, we currently have a standard mechanism where the XS > bits get set in sstatus and the actual save/restore code is hidden behind an > SBI call. That call doesn't currently exist, but if we just go ahead and > add one it should be easy to support this from within Linux. We'll need to > figure out how to enable these custom extensions from userspace, but that > seems tractable as well. We'll probably also want some fast-path for the V > extension (and any other stateful standard extensions), but I think as long > as the V extension adds a quick check for dirtiness then it's not a big > deal. > > Do you guys have stateful extensions? We're trying really hard to avoid > them at SiFive because they're a huge headache, so unless there's a > compelling base of software using one I don't want to go add support if we > can avoid it. Currently no, but the future is hard to see. As long as the extensible freedom claimed by the RISC-V foundation remains true, such extensions may have their role to play. Don't worry now, I was just to give a example that in some possible vendor-specific cases the kernel cannot keep itself from involving.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, 31 Oct 2018 17:55:42 PDT (-0700), alan...@andestech.com wrote: On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote: On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote: > I agree that we need a place for vendor-specific ISA extensions and > having vendor-specific directories is also good. The only sensible answer is that we should not allow vendor specific extensions in the kernel at all. ... How can this even be possible if a extension includes an extra register set as some domain-specific context? In such a case, kernel should at least process the context during any context switch, just like how it deals with the FP context. Ya, I think there are cases where vendor-specific extensions are going to be necessary to handle within the kernel. Right now the only one I can think of is the performance counter stuff, where we explicitly allow vendor-specific counters as part of the ISA spec. For stateful extensions, we currently have a standard mechanism where the XS bits get set in sstatus and the actual save/restore code is hidden behind an SBI call. That call doesn't currently exist, but if we just go ahead and add one it should be easy to support this from within Linux. We'll need to figure out how to enable these custom extensions from userspace, but that seems tractable as well. We'll probably also want some fast-path for the V extension (and any other stateful standard extensions), but I think as long as the V extension adds a quick check for dirtiness then it's not a big deal. Do you guys have stateful extensions? We're trying really hard to avoid them at SiFive because they're a huge headache, so unless there's a compelling base of software using one I don't want to go add support if we can avoid it.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, 31 Oct 2018 17:55:42 PDT (-0700), alan...@andestech.com wrote: On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote: On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote: > I agree that we need a place for vendor-specific ISA extensions and > having vendor-specific directories is also good. The only sensible answer is that we should not allow vendor specific extensions in the kernel at all. ... How can this even be possible if a extension includes an extra register set as some domain-specific context? In such a case, kernel should at least process the context during any context switch, just like how it deals with the FP context. Ya, I think there are cases where vendor-specific extensions are going to be necessary to handle within the kernel. Right now the only one I can think of is the performance counter stuff, where we explicitly allow vendor-specific counters as part of the ISA spec. For stateful extensions, we currently have a standard mechanism where the XS bits get set in sstatus and the actual save/restore code is hidden behind an SBI call. That call doesn't currently exist, but if we just go ahead and add one it should be easy to support this from within Linux. We'll need to figure out how to enable these custom extensions from userspace, but that seems tractable as well. We'll probably also want some fast-path for the V extension (and any other stateful standard extensions), but I think as long as the V extension adds a quick check for dirtiness then it's not a big deal. Do you guys have stateful extensions? We're trying really hard to avoid them at SiFive because they're a huge headache, so unless there's a compelling base of software using one I don't want to go add support if we can avoid it.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote: > On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote: > > I agree that we need a place for vendor-specific ISA extensions and > > having vendor-specific directories is also good. > > The only sensible answer is that we should not allow vendor specific > extensions in the kernel at all. ... How can this even be possible if a extension includes an extra register set as some domain-specific context? In such a case, kernel should at least process the context during any context switch, just like how it deals with the FP context. > ... We need to standardize cache flushing > and we need to do it soon and not introduce horrible bandaids because > the foundation did not do its work. > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, Oct 31, 2018 at 07:17:45AM -0700, Christoph Hellwig wrote: > On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote: > > I agree that we need a place for vendor-specific ISA extensions and > > having vendor-specific directories is also good. > > The only sensible answer is that we should not allow vendor specific > extensions in the kernel at all. ... How can this even be possible if a extension includes an extra register set as some domain-specific context? In such a case, kernel should at least process the context during any context switch, just like how it deals with the FP context. > ... We need to standardize cache flushing > and we need to do it soon and not introduce horrible bandaids because > the foundation did not do its work. > > ___ > linux-riscv mailing list > linux-ri...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, Oct 31, 2018 at 10:27 AM Palmer Dabbelt wrote: > > On Wed, 31 Oct 2018 04:16:10 PDT (-0700), a...@brainfault.org wrote: > > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen 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
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, Oct 31, 2018 at 10:27 AM Palmer Dabbelt wrote: > > On Wed, 31 Oct 2018 04:16:10 PDT (-0700), a...@brainfault.org wrote: > > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen 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
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, 31 Oct 2018 04:16:10 PDT (-0700), a...@brainfault.org wrote: On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen 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.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, 31 Oct 2018 04:16:10 PDT (-0700), a...@brainfault.org wrote: On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen 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.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote: > I agree that we need a place for vendor-specific ISA extensions and > having vendor-specific directories is also good. The only sensible answer is that we should not allow vendor specific extensions in the kernel at all. We need to standardize cache flushing and we need to do it soon and not introduce horrible bandaids because the foundation did not do its work.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, Oct 31, 2018 at 04:46:10PM +0530, Anup Patel wrote: > I agree that we need a place for vendor-specific ISA extensions and > having vendor-specific directories is also good. The only sensible answer is that we should not allow vendor specific extensions in the kernel at all. We need to standardize cache flushing and we need to do it soon and not introduce horrible bandaids because the foundation did not do its work.
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On 10/31/18, Anup Patel wrote: > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen > 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. Agreed, we did this on arm32 in the past, and it took us a long time to change all the modern platforms (ARMv6/7/8) to be usable in a shared kernel. It's better to avoid that and keep everything together like we did on arm64 from the start. One thing we do on arm32 is to support combinations of different instruction set variants in a combined kernel through callback pointers that turn into direct function calls when the kernel is configured for only a single CPU type. This might be something to add later on riscv, but I probably wouldn't do it right away. Arnd
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On 10/31/18, Anup Patel wrote: > On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen > 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. Agreed, we did this on arm32 in the past, and it took us a long time to change all the modern platforms (ARMv6/7/8) to be usable in a shared kernel. It's better to avoid that and keep everything together like we did on arm64 from the start. One thing we do on arm32 is to support combinations of different instruction set variants in a combined kernel through callback pointers that turn into direct function calls when the kernel is configured for only a single CPU type. This might be something to add later on riscv, but I probably wouldn't do it right away. Arnd
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen 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. Regards, Anup
Re: [RFC 0/2] RISC-V: A proposal to add vendor-specific code
On Wed, Oct 31, 2018 at 4:06 PM Vincent Chen 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. Regards, Anup
[RFC 0/2] RISC-V: A proposal to add vendor-specific code
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. Vincent Chen (2): RISC-V: An infrastructure to add vendor-specific code. RISC-V: make dma_map_ops work without cache coherent agent arch/riscv/Kconfig | 49 + arch/riscv/Makefile |6 + arch/riscv/include/asm/sbi.h|6 + arch/riscv/include/asm/vendor-hook.h| 13 ++ arch/riscv/kernel/cpufeature.c |5 + arch/riscv/kernel/setup.c |6 +- arch/riscv/vendor-nds/Kconfig | 29 +++ arch/riscv/vendor-nds/Makefile |1 + arch/riscv/vendor-nds/cache.c | 83 arch/riscv/vendor-nds/include/asm/csr.h | 32 +++ arch/riscv/vendor-nds/include/asm/dma-mapping.h | 24 +++ arch/riscv/vendor-nds/include/asm/proc.h| 17 ++ arch/riscv/vendor-nds/include/asm/sbi.h | 17 ++ arch/riscv/vendor-nds/include/asm/vendor-hook.h |8 + arch/riscv/vendor-nds/noncoherent_dma.c | 254 +++ arch/riscv/vendor-nds/setup.c | 16 ++ 16 files changed, 565 insertions(+), 1 deletions(-) create mode 100644 arch/riscv/include/asm/vendor-hook.h create mode 100644 arch/riscv/vendor-nds/Kconfig create mode 100644 arch/riscv/vendor-nds/Makefile create mode 100644 arch/riscv/vendor-nds/cache.c create mode 100644 arch/riscv/vendor-nds/include/asm/csr.h create mode 100644 arch/riscv/vendor-nds/include/asm/dma-mapping.h create mode 100644 arch/riscv/vendor-nds/include/asm/proc.h create mode 100644 arch/riscv/vendor-nds/include/asm/sbi.h create mode 100644 arch/riscv/vendor-nds/include/asm/vendor-hook.h create mode 100644 arch/riscv/vendor-nds/noncoherent_dma.c create mode 100644 arch/riscv/vendor-nds/setup.c
[RFC 0/2] RISC-V: A proposal to add vendor-specific code
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. Vincent Chen (2): RISC-V: An infrastructure to add vendor-specific code. RISC-V: make dma_map_ops work without cache coherent agent arch/riscv/Kconfig | 49 + arch/riscv/Makefile |6 + arch/riscv/include/asm/sbi.h|6 + arch/riscv/include/asm/vendor-hook.h| 13 ++ arch/riscv/kernel/cpufeature.c |5 + arch/riscv/kernel/setup.c |6 +- arch/riscv/vendor-nds/Kconfig | 29 +++ arch/riscv/vendor-nds/Makefile |1 + arch/riscv/vendor-nds/cache.c | 83 arch/riscv/vendor-nds/include/asm/csr.h | 32 +++ arch/riscv/vendor-nds/include/asm/dma-mapping.h | 24 +++ arch/riscv/vendor-nds/include/asm/proc.h| 17 ++ arch/riscv/vendor-nds/include/asm/sbi.h | 17 ++ arch/riscv/vendor-nds/include/asm/vendor-hook.h |8 + arch/riscv/vendor-nds/noncoherent_dma.c | 254 +++ arch/riscv/vendor-nds/setup.c | 16 ++ 16 files changed, 565 insertions(+), 1 deletions(-) create mode 100644 arch/riscv/include/asm/vendor-hook.h create mode 100644 arch/riscv/vendor-nds/Kconfig create mode 100644 arch/riscv/vendor-nds/Makefile create mode 100644 arch/riscv/vendor-nds/cache.c create mode 100644 arch/riscv/vendor-nds/include/asm/csr.h create mode 100644 arch/riscv/vendor-nds/include/asm/dma-mapping.h create mode 100644 arch/riscv/vendor-nds/include/asm/proc.h create mode 100644 arch/riscv/vendor-nds/include/asm/sbi.h create mode 100644 arch/riscv/vendor-nds/include/asm/vendor-hook.h create mode 100644 arch/riscv/vendor-nds/noncoherent_dma.c create mode 100644 arch/riscv/vendor-nds/setup.c
