For the current V extension, it's correct to treat both vcsr and vstart as 32-bit registers. I agree the spec should clearly indicate whether or not these registers will always be 32 bits (like

Hi,all Debuggers can use abstract commands to access CSRs. When using abstract commands, debuggers need to specify the bit width of CSRs. The bit widths of vcsr and vstart are not clearly defined in

| Reviving this old thread with a question and a suggestion: | Question: What is the use case for supporting non-idempotent memory in a RISC-V Vector implementation as a part of a general-purpose |

Upstream maniline binutils had rvv 1.0 support added recently. This isn't in any release yet, so you have to use the top of the development tree. Upstream LLVM has had rvv support for a while,

Reviving this old thread with a question and a suggestion: Question: What is the use case for supporting non-idempotent memory in a RISC-V Vector implementation as a part of a general-purpose rich-OS

I am working on some experiment and I need to simulate RVV r1.0. Is spike my best bet for this? All I want to start with is writing bare metal assembly, and copy some memory buffers between the sim

Simple implementations could simply execute it sequentially. Or have the trap handler execute the loads sequentially if any of them fault. We don't care how slowly malicious code runs. It plays just

On 2021-11-17 10:33 p.m., Bill Huffman wrote: First there is currently no ff gather. But if there were, the vl would need to be truncated to the first in sequence that

So if I set up indexes on a ff gather so that I ensure the first one is legal while the rest access pages I want to probe, how does the higher privilege software know I learned about all those

The trap if first address bad is stipulated behaviour. The other are not specified in the vector extension , but 1. the counter is part of the generalized performance spec. 2. Always trap but allow

Are the mechanisms you mentioned hypothetical future ISA extensions, or something included in the current vector extension? In particular, I don't see anything about M-mode and/or HS-mode requesting a

that should have been "The HS is in control, it can "leak" or not as it sees fit" obviously. On 2021-11-17 9:16 p.m., David Horner via lists.riscv.org wrote:

On 2021-11-17 8:45 p.m., Andrew Waterman wrote: The VS having this awareness can be very beneficial. It allows the OS to better manage its resources. It can switch to

Yeah, agreed that detecting paged-out pages is a similar information leak. (Though I think COW is not relevant here, since we're only talking about load instructions.)

The physical address space that the hypervisor tells the guest about may not match the one installed in hgatp. For instance, some pages of the guest's memory might be marked copy-on-write or swapped

Perhaps I'm being obtuse, but I'm having trouble understanding why this specific case is a concern: it's within VS-mode's purview to know anything and everything about the guest physical address

On 2021-11-17 7:18 p.m., Jonathan Behrens wrote: yes. I will below. It could depending upon what implementation details are designed into the hart. Control Mechanisms:

Earlier Intel Larrabee design had variant that required loop around unsuccessful gather according to mask bits. I believe some folks on this list were responsible for that... Krste

At one point I thought that in the case of a gather load the FFR could return an arbitrary mask. But reading the documentation again today I think it's constrained to a (possibly empty) run of 1s

A paranoid hypervisor could restrict ff loads to always reduce to vl=1, or only after x failed probes, for example. Krste