That makes sense, but it does mean that discovery gets more complicated, and (maybe) you need to build separate device trees for each. But maybe that has to happen anyway? I don't know if DT can be pa

The implication of that is that either - there is an mmio address that can access different instantiations of mtime/mtimecmp for each requesting hart (depending on the "cluster") - each "cluster" can

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. a

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)

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, Zb

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 t

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 ma

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 atte

I'm also unclear of the "identifier" you mention for other unmentioned option value (e.g. your 64b cache block size example). Who is the consumer of that identifier? Is this a value you would expect t

If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense. They are names for the values of architectural options of extensions that already ex

That's a bit looser a definition than I'd expect, but that explains your comments, certainly. Thx.

Don't they even define whether restartability is required or not?

Now we're starting to drill down appropriately. There is a wide range. This is me thinking out loud and trying desperately to avoid the real work I should be doing: - A watchdog time event can cause a

What you describe sounds very implementation dependent; I had always imagined that mtime would not be broadcast, but an mtime count enable bit would be, to keep the local copy synched. That has its ow

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

Actually, you point out one more possible difference: "PMP matching needs a priority decoder by definition of the spec to match the lowest entry. The server extension in the platform spec is requiring

I had exactly the same question: hardwiring anything reduces validation effort, it doesn't increase it. Also "There is no way, in the positive, to declare a region as M-mode only. That would be the op

My issue here is that I'm still not seeing what this does that the proposed ePMP definition doesn't already do. What I heard is that it's too expensive or too complex, but that's a bit vague. Could we

Exactly; my use of the term "background" is a lower priority (==higher entry index) which will be overridden by any matching entry with a lower index In this particular case, the background entry woul

ePMP makes several changes. One is to separate M for S/U. Another is to then add shared regions (with specific permissions) on top of that. Another is to temporarily allow locked behavior without actu