+1

Hi all, Andy and I would like to propose the following charter for the CMO TG for approval: The Cache Maintenance Operation, or CMO, task group intends to define data cache maintenance operations for

I'll leave the wording decision up to John Hauser.

OK, that makes sense. I think that this minor change would be clearer (and I can make a PR if you agree): "HLVX cannot override machine-level physical memory protection (PMP), so attempting to read

It means what it says. Execute-only PMP regions (or PMA regions, for that matter) cause HLVX to raise an exception. This is consistent with how mstatus.MXR is defined. (The implication is that code

HLVX requires execute permission "during address translation" and explicitly requires PMP read access. Since PMP is not address translation, does HLVX require PMP execute permission in addition to

The 16-PMP scheme is the only ratified one. It's highly unlikely, but the CSRs allocated to the 64-PMP scheme might not ultimately be so purposed. The most conservative option is to stick to the

Hello, Sorry about reviving an old post but I would like to verify as I do not find this clear in the privileged draft. If a decision is taken to implement exactly 16 PMP registers, should accesses to

Paul Donahue wrote: It seems the algorithm in section 4.3.2 was edited since section 5.5.1 was written. I'm looking at updating section 5.5.1 to adapt to the changes. - John H.

I think that there are a few problems in section 5.5.1 of the hypervisor spec. It says that G-stage translation follows the same algorithm as section 4.3.2 with a few changes. However: 1. the first

Hi Yifei, Both full emulated I/O devices (e.g. UART, RTC, PCIe devices, etc) and paravirtual I/O devices (e.g. VirtIO devices, XenPV devices etc) have MMIO registers which are trap-n-emulated by

i remember using DEC VAX ancillary control processes and writing knob and trackball device drivers in user land in the early 80s. I tried to find something describing this but I think it is lost to

Hi Anup, Sorry for the confusing description of the background in this proposal. To be clear, we here divide the implementation of trap-and-emulated I/O devices into full emulated I/O devices and

Hi John, Yes, we believe that the new interrupt architecture and an IOMMU, which is regarded as a pass-through method as we knew, can indeed minimize the number of times of GuestOS exiting. However,

Hi, Thanks for your comment. To solve the security problem about the URET instruction, we further add a field, called HUR, in hstatus to control the behavior of URET instruction. When the

I was arguing something different. If an extension can be disabled (and is)- what happens when you execute a disabled instruction? Trap or unspecified? Not all extensions are instruction related, of

Errr... disregard that second part, I misread the previous email

Perhaps “all state no longer associated with any active extension is UNSPECIFIED”? But it also might be slightly cleaner to talk about the state being unspecified right after an extension is

OK by me. PR is here: https://github.com/riscv/riscv-isa-manual/pull/585

Given the comments excerpted down below that argue for specifying that extension state is UNSPECIFIED after being disabled and then re-enabled, and given that no particular arguments or use cases have