tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

The memory map isn't in the spec because it's platform-defined. Some folks use the SiFive CLINT as a de facto standard for the address map for mtime[cmp] and MSIP registers. QEMU supports this as

By andrew@... · #154 ·

Address Mapping Questions

Dear team, This may be a basic question: I am trying to figure out where in the physical memory map are the "mtime" and "mtimecmp" registers to be placed. Per the privileged spec, these registers are

By Nagendra Gulur · #153 ·

Re: Boot code awareness of the Hypervisor extension

I agree with this one example. But I'm also trying to address the broader issue and ask the more general architecture-level question (that I originally stated), i.e. must new implementations that

By Greg Favor · #152 ·

Re: Boot code awareness of the Hypervisor extension

If hstatus.SPV=0, then SRET behaves like normal. And since that bit will stay zero unless some code messes with hypervisor CSRs, it should be sufficient to just have the reset state initialize it that

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

Re: Boot code awareness of the Hypervisor extension

But there is existing architecture functionality (e.g. the SRET instruction) that is affected by certain bits in a hypervisor CSR - which would be in effect because of misa.H=1. If it was just a

By Greg Favor · #150 ·

Re: Boot code awareness of the Hypervisor extension

Why would that be a problem? As long as you don't issue any HS-mode instructions or touch any of the hypervisor CSRs then any code should run the same. Jonathan

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

Re: Boot code awareness of the Hypervisor extension

One issue is that the current Privileged spec requires that misa.H is reset to '1' if the Hypervisor extension is implemented. Unaware boot code will leave that set and then problems will ensue

By Greg Favor · #148 ·

Re: Boot code awareness of the Hypervisor extension

I would expect the rule be that either the reset state properly initializes all the H-extension CSRs or the boot code. Thus if you want hardware to be backwards compatible with legacy boot code, you

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

Boot code awareness of the Hypervisor extension

We have run across the situation of running "legacy" (i.e. current) boot code that naturally is unaware of the possible existence of the Hypervisor extension. Since, on a platform that does implement

By Greg Favor · #146 ·

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

The Hypervisor extension adds bits to some of the existing M-mode CSR's. When this extension is not implemented, these bits are hardwired to zero. When the extension _is_ implemented these bits

By Greg Favor · #145 ·

Re: Extending the number of PMP entries

yes, fair enough. Leaving it unrestricted is certainly the most flexible way Tariq

By Mr Tariq Kurd <tariq.kurd@...> · #144 ·

Re: Extending the number of PMP entries

The only reason that you might want to enforce some ordering is just so setup code doesn't have to check every single entry to see if it's writable or not. That is not a great reason for something

By Allen Baum · #143 ·

Re: Extending the number of PMP entries

I've merged the pull request, but comments are obviously still welcome. I recommend adding them on github at https://github.com/riscv/riscv-isa-manual/pull/525 to reduce the likelihood that they get

By andrew@... · #142 ·

Re: Extending the number of PMP entries

Hardwired nonzero PMP registers are likely to start at the zeroth entry, because that way they have highest priority. If they came at the end, writable PMPs could override them. Once we admit that

By andrew@... · #141 ·

Re: Extending the number of PMP entries

I don’t think I understand the your comment, Andrew. I interpreted Tariq saying we essentially restrict RdOnly zero entries to always be the larger numbered ones. (Sort is the way that HartIndexes

By Allen Baum · #140 ·

Re: Extending the number of PMP entries

I see what you're getting at, but since some vendors will (rightly) choose to hardwire some PMP registers, the sentiment seems impractical to enforce.

By andrew@... · #139 ·

Re: Extending the number of PMP entries

Thanks for this Andrew, it’s really useful. My only comment is: “Up to 64 PMP entries are supported. Implementations may implement zero, 16, or 64 PMP CSRs. All PMP CSR fields are WARL and

By Mr Tariq Kurd <tariq.kurd@...> · #138 ·

Re: Extending the number of PMP entries

Same understanding here Anup. The most of uses are runtime debug, trace, compliance validation and POST time firmware (configures H/W and also builds up DT for the software you mentioned). Abner

By Abner Chang <abner.chang@...> · #137 ·

Re: Extending the number of PMP entries

You are free to add it in “RISC-V configuration structure” but from Linux, Hypervisors and M-mode RUNTIME firmware perspective we don’t’ need it. All these software will: Either use

By Anup Patel · #136 ·

Re: Extending the number of PMP entries

Missed this mail while I was replying to Andrew. Same feedback to your comment in that reply.

By Abner Chang <abner.chang@...> · #135 ·

1181 - 1200 of 1334

Home Hashtags Subgroups Terms