Can risc-v processors perform speculative instruction fetches in MMIO space?

[san zhang]

Can risc-v processors perform speculative instruction fetches in MMIO space? I'm confused by what's in the summary of instruction manual 3.6.7 (Idempotency PMAs). "Furthermore, when a non-speculative instruction fetch is performed, an implementation is permitted to additionally read any of the bytes within the next naturally aligned power-of-2 region of the same size." What does this mean? Can you list some application scenarios to help me understand?

[BGB]

> scenarios to help me understand? 123.jpg
>

I would say, trying to run any code from MMIO areas is not a good idea,
in any case.

In my CPU core (not natively RISC-V, but can run RV64G as a sub-mode),
code execution from MMIO areas is not allowed, at all, and in effect,
RAM vs MMIO have different ways of accessing and using the bus (in RAM
areas, it fetches and writes back cache lines, in MMIO, every access
effectively takes a round-trip around the bus; and the devices on the
MMIO part of the bus don't support cache-line access).

This is partly because every access to an MMIO device may potentially
reflect or modify the internal working state of the device being
accessed, performed at the moment it is being accessed.



But, generally when an instruction fetch is performed, the cache might
operate in terms of cache lines, and then extract the instruction(s) it
needs from them.

So, for example, if one is running code at 0x011088Ex, the CPU might
also fetch memory from 0x011088Fx or maybe even 0x0110890x (or, if one
is near a page boundary, it might cross into the next page, etc...).
Mostly depending on the size of the cache line.

Access to normal data areas of RAM is typically similar, with the cache
lines hanging around in the L1 caches or similar until they need to be
evicted back out to the L2 cache, or to external RAM (and the large flat
address space where any piece of memory can be accessed at any moment,
or where memory written is one thread is seemingly immediately visible
in other threads, etc, is, to some extent, an illusion).


For actual hardware interfaces (and MMIO in general), this illusion is
not good enough, so it needs to pays some extra penalties to do it for real.

Well, except for some things like graphics framebuffers where one can
get along OK with potential inconsistencies (if a block of pixels on
screen isn't updated at exactly the right time, no one will likely
notice or care).


> --
> You received this message because you are subscribed to the Google
> Groups "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to isa-dev+u...@groups.riscv.org
> <mailto:isa-dev+u...@groups.riscv.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/260f7612-5cdb-4a21-b3ca-939b08902846n%40groups.riscv.org <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/260f7612-5cdb-4a21-b3ca-939b08902846n%40groups.riscv.org?utm_medium=email&utm_source=footer>.

[Daniel Petrisko]

The typical two scenarios:

- cache line sized read from DRAM (idempotent region). Say 64B read where 60B are speculative.
- word sized read from bootrom (non-idempotent region). 4B read where none of it is speculative.

Basically when reading from MMIO you don’t want to fetch anything more than you know you’ll need. For instance, if you’re fetching the last word of the bootrom you don’t want to speculate the next word because it may hang your memory system.

Best,
-Dan

> On May 26, 2024, at 11:27 AM, BGB <cr8...@gmail.com> wrote:

> To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/21c93ab5-b8c1-4e51-bd8d-1c1acf8d6381%40gmail.com.

[Greg Favor]

The arch text in question is saying two things:

1) A hart may initially fetch from an implementation-specific napot region (e.g. often a 4 KB page in "apps" processors) only non-speculatively.

2) Once a hart has fetched into a napot region non-speculatively, the hart is free to speculatively fetch from any and all other parts of that region.

This prevents general speculative accesses to MMIO addresses, but allows for code to be fetched from MMIO regions in a reasonably performant manner (similar to what other architectures allow).

Greg 

On Sun, May 26, 2024, 6:05 AM san zhang <mayfly...@gmail.com> wrote:

Can risc-v processors perform speculative instruction fetches in MMIO space? I'm confused by what's in the summary of instruction manual 3.6.7 (Idempotency PMAs). "Furthermore, when a non-speculative instruction fetch is performed, an implementation is permitted to additionally read any of the bytes within the next naturally aligned power-of-2 region of the same size." What does this mean? Can you list some application scenarios to help me understand?

--

You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/260f7612-5cdb-4a21-b3ca-939b08902846n%40groups.riscv.org.

[Allen Baum]

As Greg said, but note that *typically* that 'implementation specific napot region' may be as small as 4B - so don't expect to get reasonable performance from code in that space..
And, in the case of this MMIO space being shared with other harts that might write to it, you need to be very careful you're not executing stale data.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/CA%2BQh7TmQbOfw4w7hFFYAe10OQLn6n3zH%3DHmYzDdDqN5CfKS02w%40mail.gmail.com.

[san zhang]

Thank you very much for all the responses. The answers provided by Greg Favor and Allen Baum have helped me greatly in resolving many of my confusions. I also appreciate the helpful responses from other friends.