Hi Aaron, I was under the impression that it is decided not to use the extension names mentioned in profile spec. Sorry I didn't know you are still working with TSC to conclude on this. In that

I don't think we should submit this one until we settle on how we convey behaviors outside of an ISA string. I suspect that will change so we should anticipate that. Right now we have ISA string plus

Hi All, Based on feedback, below is the updated draft proposal of the SBI Debug Console Extension ... The motivations behind this proposal is as follows: 1) There is no new SBI extension replacing

Hi, There are two major issues in passing virtual address of string: 1) A rogue supervisor software can pass a virtual address mapped to a physical address not accessible to it. 2) To access a

Hi All, We plan to send below two ECRs to UEFI forum on 08/08/2022. These two ECRs don't have any dependency on any unfrozen specs. Getting these two ECRs accepted by UEFI forum would help us to

Hi Group, I have an idea on addr_lo and addr_hi combination. What will happen if we ask supervisor to provide the string address in a probable virtual address? In this way the supervisor won't need to

For SBI spec, we have avoided separate function signatures for RV32 and RV64 so better to prefer other options. If we want to combine "addr_lo" and "addr_hi" into one parameter then uint64_t is

It is really necessary to have two long parameters for a physical address on RV64? Clearly this is necessary for RV32, where the maximum physical address is greater than XLEN, but that is not the

<heinrich.schuchardt@...> wrote: Okay, I will update the text. Yes, the accessibility check on physical address parameters is very important for SBI implementation (M-mode firmware,

We should also cover the case that only a part of the memory area is accessible by S-mode. %s/accessible/entirely accessible/ It is unclear if the SBI is obliged to check S-mode accessibility. The

Hi All, Based on feedback, below is the updated draft proposal of the SBI Debug Console Extension ... The motivations behind this proposal is as follows: 1) There is no new SBI extension replacing

Hi All, To support native debugging in S-mode and VS-mode, we need a SBI Debug Trigger extension which complements the Sdtrig extension. Below is the draft proposal of the SBI Debug Trigger

My point is that the information, regardless of format, needs to be conveyed in some manner to the OS. There's no getting around that aspect. We need to identify 1. all the things the OS needs and 2.

Allen, Rereading your comment, I realised that something was off (as I didn't have a line 244) — looks like I missed the additional tabs on the inline preview of the sheet in the mail

But the problem is that a profile is just putting an extension-style name (e.g. Zi* or Ss*) to a specific combination of an option or parameter, and a specific value for that option or parameter.

This was a point I tried to make in another thread about tech-config and profiles. Support for a profile implies support for all the extensions mandated by the profile (but still leaves unspecified

Ah, never mind. My version of the spreadsheet opens to sheet3, and that's what has the complete list. The other sheets were used to develop this one. I will rename the sheet and put it in the front.

They are marked in the spreadsheet as "Ignored in v1.0", for what it's worth, but I could make it more obvious (or better, move them to a separate sheet-- done)

Alan, Given the recent troubles with people having taken extensions in the priv/unpriv spec documents as being official even though they are listed as unratified, I would suggest not listing

Allen, You should check with the tpm's as to where there is a complete list of all ratified extensions. Somewhat equivalently the RVA22 S and U profiles, by requirement, list and categorize all S and