tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Topics Expanded Polls

Export Group Data

Between

and

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

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

By Guo Ren · #1055 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

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

By Guo Ren · #1054 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

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

By Phil McCoy · #1053 ·

Re: Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

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

By Ved Shanbhogue · #1052 ·

Fast-track extension proposal for "Sv32 Svnapot and Svpbmt"

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

By Guo Ren · #1051 ·

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

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.

By Aaron Durbin · #1050 ·

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

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.

By Greg Favor · #1049 ·

Re: [RISC-V][privileged-software] [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

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

By Greg Favor · #1048 ·

Re: [RISC-V][privileged-software] [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

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

By Philipp Tomsich <philipp.tomsich@...> · #1047 ·

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

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

By Allen Baum · #1046 ·

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

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

By Aaron Durbin · #1045 ·

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

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

By Greg Favor · #1044 ·

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

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

By Aaron Durbin · #1043 ·

Re: [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

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

By Allen Baum · #1042 ·

Re: [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

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

By Aaron Durbin · #1041 ·

Re: [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

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'

By Aaron Durbin · #1040 ·

Re: [RISC-V][tech-os-a-see] [RISC-V] [tech-unprivileged] Direction of Identifying 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

By Greg Favor · #1039 ·

Re: [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

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

By Allen Baum · #1038 ·

Re: [RISC-V] [tech-unprivileged] Direction of Identifying Extensions

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

By Allen Baum · #1037 ·

Direction of Identifying Extensions

Hi All, First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted. We can convene

By Aaron Durbin · #1036 ·

281 - 300 of 1334

Home Hashtags Subgroups Terms