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

I'm not sure what you're referring to Line 244 list Zihintpause Lines 180-188 list Zvlsseg, Zvamo, Zvediv, Zvqmac, Zve32x, Zve32f, Zve64x, Zve64f, Zve64d Lines 138-147 list Zba, Zbb, Zbc, Zbe, Zbf,

Duplicating the information (i.e. having the individual extensions marked and the profile itself indicated) seems like an error-prone proposal, unless we mandate/enforce consistency checking. Given

Greg and I did discuss having Unified Discovery (UD) description macros for profiles, e.g. an RV22A bit that indicates support for all of the individual extensions (and option value ranges) required

Allen, There is no 'RVB'... and even the basic options on Zb[abcs] open up 16 possibilities. Similarly 'V' is a not a single option, but multiple Zv* options. Finally, Zihintpause is

FYI: here is a rough initial draft of the architectural options that I've been able to dig up. I know that this is very, very likely to be incomplete. This is written from the perspective of how to