Message-ID: <mhng-fa5b8aa8-375c-4780-a90d-64511f76ab07@palmer-ri-x1c9>
Date: Mon, 22 Jul 2024 16:45:05 -0700 (PDT)
From: Palmer Dabbelt <palmer@...belt.com>
To: Charlie Jenkins <charlie@...osinc.com>
CC: ajones@...tanamicro.com, Paul Walmsley <paul.walmsley@...ive.com>,
  aou@...s.berkeley.edu, Conor Dooley <conor.dooley@...rochip.com>, Evan Green <evan@...osinc.com>,
  andy.chiu@...ive.com, linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org,
  peterlin@...estech.com
Subject:     Re: [PATCH v3 0/4] riscv: Separate vendor extensions from standard extensions

On Mon, 22 Jul 2024 13:23:48 PDT (-0700), Charlie Jenkins wrote:
> On Mon, Jul 22, 2024 at 02:32:49PM -0500, Andrew Jones wrote:
>> On Fri, Jul 19, 2024 at 09:15:17AM GMT, Charlie Jenkins wrote:
>> > All extensions, both standard and vendor, live in one struct
>> > "riscv_isa_ext". There is currently one vendor extension, xandespmu, but
>> > it is likely that more vendor extensions will be added to the kernel in
>> > the future. As more vendor extensions (and standard extensions) are
>> > added, riscv_isa_ext will become more bloated with a mix of vendor and
>> > standard extensions.
>>
>> But the mix doesn't hurt and with everything in one place it makes it easy
>> to know where to look.
>>
>> >
>> > This also allows each vendor to be conditionally enabled through
>> > Kconfig.
>>
>> We can do that anyway by adding an extension menu for each vendor. If we
>> don't want a vendor's extensions bloating the array then we just need
>> some #ifdefs, e.g.
>>
>> @@ -405,7 +405,9 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
>>         __RISCV_ISA_EXT_DATA(svinval, RISCV_ISA_EXT_SVINVAL),
>>         __RISCV_ISA_EXT_DATA(svnapot, RISCV_ISA_EXT_SVNAPOT),
>>         __RISCV_ISA_EXT_DATA(svpbmt, RISCV_ISA_EXT_SVPBMT),
>> +#ifdef RISCV_ISA_VENDOR_EXT_ANDES
>>         __RISCV_ISA_EXT_DATA(xandespmu, RISCV_ISA_EXT_XANDESPMU),
>> +#endif
>>  };
>>
>>
>> So, I'm not convinced we want the additional complexity of vendor
>> extension arrays, but maybe I'm missing something.
>>
>> Thanks,
>> drew
>
> Vendor extensions are non-standard behavior, so this is largely an
> organizational effort. A benefit this provides is to delegate
> maintainership of vendor extensions to the vendor. Additionally, this
> separation of vendor extensions prevents changes to vendor extensions
> from affecting standard extensions and vice versa.
>
> Another motivation for this is that I expect vendor extensions to be
> temporary fixes in a lot of cases. A good example is xtheadvector where
> a previous version of the ratified vector spec was implemented. Another
> case is vendors creating vendor extensions while waiting for RVI
> ratification. This will cause these eventually-to-be-deprecated
> extensions to pollute the namespace and require shuffling around of the
> standard isa lists. When it's an internal structure it is less relevant,
> but it is a bigger risk when it comes to hwprobe. Allowing these kinds
> of vendor extensions into hwprobe runs the risk of causing a sparse key
> space. We may end up with many dead bits for deprecated vendor
> extensions that will never be able to be removed to maintain backward
> compatibility. Having the vendor extensions split across vendors
> streamlines the hwprobe implementation.

IIRC this came up a few times.  I think it's hard to tell which will end 
up cleaner, but it's just an internal interface and it's already written 
this way.  So I'm fine going with this as-is, if it gets clunky we can 
always change later -- at a certain point trying to predict 
endor-specific stuff just leads to insanity, I'm sure some vendor will 
figure out something crazy enough regardless of what we do...

So I've got this on staging, assuming it builds it'll end up on for-next 
soon.

Thanks!

>
> - Charlie

Powered by blists - more mailing lists