tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: xTVAL Compliance restriction proposal

The Rocket approach works here if you set the width of mtval to 1+max(VAbits,PAbits) and then sign-extend from the most-significant implemented bit. The extra 1 bit allows for zero-extension of PAs.

By andrew@... · #194 ·

Re: xTVAL Compliance restriction proposal

You said: Sign extend if translated Zero extend otherwise (I don’t think that’s is quite the same as Bare+Mmode because of MPRV, and not sure how hypervisor modes affect that) Then you said

By Allen Baum · #193 ·

Re: xTVAL Compliance restriction proposal

Coming back to designs where the implemented PA size is greater than the supported VA size (for example, 48b VA's and 50b+ PA's), and in contrast to always sign-extending when VA size is greater than

By Greg Favor · #192 ·

Re: Boot code awareness of the Hypervisor extension

It seems like Mark's FAQ suggestion was more general and different from his specific "well documented guidance" comment on this particular issue. To me this particular guidance would belong in the

By Greg Favor · #191 ·

Re: Boot code awareness of the Hypervisor extension

I think it's the kind of thing that belongs in the FAQ that Mark mentioned in his previous email.

By andrew@... · #190 ·

Re: Boot code awareness of the Hypervisor extension

This seems like a fairly big nail in the coffin for answer "A". And responses by others (e.g. Anup and Mark) also fall on the side of answer "B". Are we at a point to call the ball, i.e. adopt answer

By Greg Favor · #189 ·

Re: Boot code awareness of the Hypervisor extension

Thank you. If I understand this correctly I agree with all you have said. If this is a once at boot time requirement regardless of mode and there is a reasonable way to do it, then i concur that well

By mark · #188 ·

Re: Boot code awareness of the Hypervisor extension

FWIW, I think supervisor mode already follows answer "B", inasmuch as the satp and medeleg registers are not reset. Consider M-mode software written to run on a system with only M and U modes, but

By andrew@... · #187 ·

Re: Boot code awareness of the Hypervisor extension

This would seem to argue for answer "B" to my question. I find this preferable since it doesn't require architecture extension spec's to specify additional arch state that must be initialized by hart

By Greg Favor · #186 ·

Re: Boot code awareness of the Hypervisor extension

Mark, Hi and welcome on board the RISC-V train. I agree with the general broad issue of ecosystem compatibility and support. The much narrower current question is whether the issue I'm touching on

By Greg Favor · #185 ·

Re: Boot code awareness of the Hypervisor extension

how is this intended to work with versions? so we ratify some 1.0 spec and we come along and call it 1.1 that has additive changes, i thought i heard that ecosystem around risc-v including compilers

By mark · #184 ·

Re: Boot code awareness of the Hypervisor extension

The M-mode runtime firmware cannot be totally unaware of new extensions. At least, this is true for H-extension. Currently M-mode runtime firmware (OpenSBI) does following to support

By Anup Patel · #183 ·

Re: Boot code awareness of the Hypervisor extension

I want to bring back up the Yes/No question I posed a couple of weeks ago - in which I was looking for a clear architectural statement of principle as to whether: A) A new architecture extension must

By Greg Favor · #182 ·

Re: Appearance of new M-mode CSR bits when Hypervisor is disabled

Jonathan Behrens wrote: It seems obvious, right? :^) A small problem is that most of the extensions are actually defined in the unprivileged ISA document, which speaks a few times of

By John Hauser · #181 ·

Re: Appearance of new M-mode CSR bits when Hypervisor is disabled

My response to Allen's post and my use of "unimplemented" in quotes was referring to the H extension spec's statement that "When misa[7] is clear, the hart behaves as though this extension were not

By Greg Favor · #180 ·

Re: Appearance of new M-mode CSR bits when Hypervisor is disabled

Couldn't you just change the wording to be "disabled" when referring to having misa.H=0 and leave "unimplemented" to mean having misa.H hardwired to 0? Jonathan

By Jonathan Behrens <behrensj@...> · #179 ·

Re: Appearance of new M-mode CSR bits when Hypervisor is disabled

While I would have to go through all the bits/fields affected by the H extension to double-check, the main issue are bits/fields that were previously reserved (and hardwired to zero). So there isn't

By Greg Favor · #178 ·

Re: Appearance of new M-mode CSR bits when Hypervisor is disabled

And we should be careful to define the corner cases, e.g. the values that are in the registers when the features are enabled: the values they last held, or undefined, or.... something else.

By Allen Baum · #177 ·

Re: Appearance of new M-mode CSR bits when Hypervisor is disabled

Thanks. This is the interpretation we expected to be correct. For the sake of some future readers of the spec that may not apply the broadest meaning of "behaves" when reading "behaves as though this

By Greg Favor · #176 ·

Re: Appearance of new M-mode CSR bits when Hypervisor is disabled

Greg Favor wrote: The overriding statement in the document is this one: When misa[7] (bit H) is clear, the hart behaves as though this extension were not implemented, .... I sympathize with

By John Hauser · #175 ·

1141 - 1160 of 1334

Home Hashtags Subgroups Terms