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

Jessica Clarke
2023-05-08T17:38:22Z

On 8 May 2023, at 18:34, Philipp Tomsich <philipp.tomsich@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@vrull.eu> wrote:
>>
>> Evan,
>>
>> On Mon, 8 May 2023 at 18:50, Evan Green <evan@rivosinc.com> wrote:
>>>
>>> On Wed, May 3, 2023 at 3:31 AM Heiko Stübner <heiko@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@vrull.eu wrote:
>>>>>> On Tue, 2 May 2023 at 09:58, Björn Töpel <bjorn@kernel.org> wrote:
>>>>>>>
>>>>>>> Philipp Tomsich <philipp.tomsich@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