That should work for me, Kumar. See you all then. -Aaron

Hi Aaron, Yes, lets meet up at the Summit in person. Let’s meet up from 3PM-4PM PST on Tuesday 12/7 at the Moscone Center outside the keynotes room 3008 on the third floor. We can take one of the

Hi Kumar, I'm willing and able to help on this front. While at the Summit, perhaps we can meet up and discuss things in person? And, I think whoever else that is interested at the Summit this week

I would be willing to propose improvements for the definition of a platform. However, I was not included in the non-public meetings on this topic, during which I understand some decisions were made,

Recommended is an indicator for the platform software and hardware vendors that the particular feature is recommended in this version of the spec while the next version of the spec might make this

IS the word "Recommended" a slightly stronger form of "Optional" (which I don't see at all)?

Hi All, As we discussed during the platform HSC meeting yesterday (Nov 29, 2021), we are calling on volunteers to own and drive the improvement of the definitions/terms used in the platform spec.

Agreed. However, the additional verbose explanation doesn't hurt. So I am inclined to keep it unless somebody is strongly opposed to it.

Hi All, The next platform HSC meeting is scheduled on Mon Nov 29th 2021 at 8AM PST. Here are the details: Agenda and minutes kept on the github

For the reason stated above. The proposal should impose no real burden on OS-A class implementations, while ensuring a reasonable upper bound on the lack of resolution/accuracy. If anything the

The SBI calling convention only defines uses of a0-a7 registers for parameter passing and return value because all other registers are assumed to be saved/restored (i.e. preserved) by the

What is the rationale for mandating any specific time period in OS-A-ish platforms? The period can be determined by device tree and/or ACPI, at least one of which is required for OS-A platforms, so

RISC-V SBI provides an interface via enironment call to provide platform agnostic features, which is similiar to operating system's syscalls. According to current SBI specification, this environment

Thanks Greg. This would be helpful to not prevent an implementation to engineer a solution but does not force an implementation to do so. I think this makes sense. Totally agree. regards ved

Absolutely. I was only suggesting a 1ns resolution and not a 1ns update rate.

Literally, such a "loosely synchronized" implementation would not be compliant with RISC-V architecture and its tight synchronization requirement. As Darius noted (below), that is just one way to

Note that ARM SBSA did not mandate a 1 GHz update rate; it only mandated a 1ns resolution - and explicitly acknowledged that updates may be at a lower rate using counter scaling. Greg

I took the opportunity to raise this with Andrew and Krste (who authored the text in question) as to the intended and proper reading of the following arch spec text: Before summarizing their response,

Fixed. Thanks.

My bad. Fixed it.