Note that in general reserved PTE bits that are non-zero - whether due to the bit still simply being reserved, or it corresponding to an unimplemented extension or to a disabled extension (via

I didn't mention satp or hgatp, because menvcfg.PBMTE would affect all of them. I agree to make it more explicit: {\tt satp}.Sv32x4 and {\tt hgatp}.Sv32x4 implementation could support Svnapot

Guo Hi - I have a few additional question I see you mentioned Sv32 implementations. I am reading it literally as Sv32 as in one of the presently defined modes of satp. I dont see anywhere in the

It's better, thx. -- Best Regards Guo Ren

I've mentioned that, and you missed it. Maybe the Latex symbol confused you. If the hypervisor didn't support Svpbmt and Svnapot, the guest couldn't run with that (Only 34-bits physical address). If

Minor wording quibble - the following text sounds very tentative and hypothetical: "Sv32 implementations could support Svnapot..." I would suggest a more assertive wording; maybe something like the

Couple of questions: 1. Treatment of Sv32x4 when mencvcfg.PBMT is set is not mentioned. Is that intensional? Or is it expected to follow the redefinition? 2. When H-extension is support and the

The current Privileged specification only defines Svnapot and Svpbmt for RV64 with the highest bits in PTE, and there are no spare highest bits in rv32 for 34-bit physical addressing. But "the lack of

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.

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

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

We would then have 2 different namespaces representing many similar constructs. Doesn't that make things more complicated? e.g. If everything that is a non-traditional extension in the Profile has a

What I'm saying (or at least my leaning) is that discovery methods should use K-V pairs as they do today (with standardized K names desired). Whereas Profiles have a more limited goal of having

It's very much the same exercise where the Profile specific options are more narrowly scoped. However, I would imagine the ones created for the Profiles to be a subset of the larger KV space as you

Unfortunately, I don't a have single term that would adequately convey the idea. Greg and I were batting around some invented words (e.g. "poption" as a portmanteau of profile-option was my first

Identifier in the sense of a short name/phrase that refers to these ideas. Consumers of that would be both software and day-to-day discussion as it's a succinct identifier that refers to an idea in

Correct. Do you have a better term that captures such notions? I fully agree that the previous definition of an extension is not the same in this case. FWIW, the profile spec uses both 'extensions'

To add on to Alan's point. These "extension" names were created simply to represent individual line items in the Profiles. In many cases these represent a one or two sentence statement in a Profile