[PATCH 0/4] Expose the isa-string via the AT_BASE_PLATFORM aux vector

[Jessica Clarke]

On 8 May 2023, at 18:34, Philipp Tomsich <philipp.tomsich at vrull.eu> wrote:
> 
> [Resend, as my mail client hadn't picked up that it should respond as
> plain-text.]
> 
> On Mon, 8 May 2023 at 19:32, Philipp Tomsich <philipp.tomsich at vrull.eu> wrote:
>> 
>> Evan,
>> 
>> On Mon, 8 May 2023 at 18:50, Evan Green <evan at rivosinc.com> wrote:
>>> 
>>> On Wed, May 3, 2023 at 3:31 AM Heiko Stübner <heiko at sntech.de> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Am Dienstag, 2. Mai 2023, 19:15:29 CEST schrieb Palmer Dabbelt:
>>>>> On Tue, 02 May 2023 02:13:10 PDT (-0700), philipp.tomsich at vrull.eu wrote:
>>>>>> On Tue, 2 May 2023 at 09:58, Björn Töpel <bjorn at kernel.org> wrote:
>>>>>>> 
>>>>>>> Philipp Tomsich <philipp.tomsich at vrull.eu> writes:
>>>>>>> 
>>>>>>>> It is a pity that the current interface was designed without involving
>>>>>>>> RVI (and that I had to ask my team to put together a patch set for
>>>>>>>> further discussion, given that none of the other major vendors in RVI
>>>>>>>> stepped forward).  I guarantee that plenty of reviewers would have
>>>>>>>> highlighted that a central registry (even if it is just a kernel
>>>>>>>> header) should be avoided.
>>>>>>> 
>>>>>>> Are you claiming that the hwprobe work was not done in the open, but
>>>>>>> secretly merged? That is not only incorrect, but rude to upstream RISC-V
>>>>>>> Linux developers. I suggest you review how you interact with upstream
>>>>>>> kernel work.
>>>>>> 
>>>>>> Please don't put words into my mouth...
>>>>>> 
>>>>>> I was merely pointing out that there was no engagement by the RVI
>>>>>> member companies (in regard to this mechanism) within RVI, which would
>>>>>> have prevented Jessica's issue.
>>>>>> This would have also helped to address the concerns on vendor-defined
>>>>>> extensions.
>>>>>> 
>>>>>> Also who do you refer to when you say "how _you_ interact"?  If it is
>>>>>> RVI that you refer to: it doesn't interact with upstream work
>>>>>> directly, as it doesn't own any engineering resources.
>>>>>> RVI provides a forum for member companies to come to an
>>>>>> understanding/design and then have the member companies perform the
>>>>>> work and take it upstream.
>>>>> 
>>>>> I'm not even sure what you're looking for here: if RVI doesn't want to
>>>>> work upstream, then complaining that RVI isn't part of upstream
>>>>> discussions is pretty pointless.
>>>>> 
>>>>>>> Why didn't RVI get involved in the review of the series? The expectation
>>>>>>> cannot be that all open source projects go to RVI, but rather the other
>>>>>>> way around.
>>>>>> 
>>>>>> That is exactly the point I was making and which you seem to miss: RVI
>>>>>> does not own any engineering resources and depends solely on its
>>>>>> member companies to project into open source projects.
>>>>>> 
>>>>>>> Take a look at commit ea3de9ce8aa2 ("RISC-V: Add a syscall for HW
>>>>>>> probing"). Your team was very much involved in the review.
>>>>>> 
>>>>>> I am aware, as I had reviewed and commented on these are well.
>>>>>> And my only request (was and) is that we need to figure out a way to
>>>>>> efficiently deal with vendor-defined extensions.
>>>>> 
>>>>> Maybe you should go talk to you team, then?  Handling vendor extensions
>>>>> via hwprobe has been discussed, sounds like you're confused again.
>>>> 
>>>> I too have this vague memory of us talking about vendor extensions,
>>>> but my memory is really bad for stuff like this, so I spent the morning
>>>> combing through all the hwprobe iterations looking for it, but so far
>>>> have only found
>>>> 
>>>> https://lore.kernel.org/lkml/CALs-HstoeoTWjTEZrLWouCgwq0t3tDB6uL=tB68RJDs1ub4Frw@mail.gmail.com/
>>>> 
>>>> I'm most likely just blind, but does someone have another pointer?
>>> 
>>> Hello! That's probably the only pointer.
>> 
>> 
>> Thanks for following up, as we were debating internally if and what discussions we had missed.
>> 
>>> 
>>> Couldn't handling vendor extensions within the hwprobe framework be as
>>> straightforward as explicitly carving out a region for them? Say
>>> 0x8000000000000000+ belongs to the vendor? The layout of keys within
>>> the vendor hwprobe region then depends on the value in mvendorid (and
>>> if the vendor so chooses, archid and impid as well). Then vendors can
>>> expose keys to their hearts (avoiding the dumb pun there) content.
>>> 
>>> We can probably skip caching the vendor keys in the vDSO for now. If
>>> it really needs to be done we can add it later.
>>> 
>>> This would enforce that there's only one "vendor" at a time for a
>>> given hart, but I think that's reasonable. Let me know what you think.
>> 
>> 
>> We generally try to treat vendor-extensions as "vendor-defined" and not "vendor-specific".  In other words, an implementor would be free to implement XVentanaCondOp and XTHeadVDot.  While we could simply alias things into the implementor's "vendor"-space, I see some benefits to having a unique id for every vendor-defined property…
>> 
>> Could we use ( 0x8000000000000000 | vendor-id << VENDOR_SHIFT | key-in-vendor-space )?
>> If so, do we have vendor-ids allocated today that we could use for this purpose?

The only somewhat useful one is mvendorid, but that’s a JEDEC thing so
if you’re an academic then yours will be 0 and we’re back to a shared
namespace.

Jess

>> Thanks,
>> Philipp.
>> 
>>> 
>>> 
>>> -Evan