Coming from an operating systems background, the concern about locking PMP entries being absolutely necessary for security comes across as overblown. I've never heard of a platform that provided locki

Remind me, did all the other proposals have a way to prevent the S/U-mode entries from being reconfigured to M-mode ones later? Locking M-mode entries doesn’t do a ton if more can be added later

Hi Andy, M-mode can use mstatus.mprv to access S/U-mode memory regions, provided that S/U-mode has read access to them. If any non-readable regions are configured then trap-and-emulate won't be possib

John Hauser wrote: I don't understand how having extra bit patterns for the PMP config registers compromise security. Isn't it pretty much a given that the values loaded into the PMP address registers

Your description of un-accelerated nested virtualization seems workable to me. I'm less sure of the proposal to avoid trapping on h<xyz> and vs<xyz> accesses. Aren't you going to run into issues with

Having SPP/SPV hold the real values makes the most sense to me. The strategy I'd expect hypervisors to use would be to set a bit before issuing any HLV or HSV instructions and clear it after. Then in

I like this plan. The one comment I have is that it seems unnecessarily opinionated about which operations trigger virtual instruction traps vs illegal instruction traps when run in VU mode. I think w

It mostly just comes down to crossing out "In VS-mode" in your list of cases for trapping when V=1: - attempts to execute an HFENCE instruction or to access an implemented hypervisor CSR or VS CSR; -

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 j

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

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

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

My understanding is that sfence.vma's are never required by the RISC-V spec, only that failing to do them can cause undesirable but well defined behavior. I'd suggest that the same be true here. We co

It depends on how you are using them. For x86-64, Linux actually only uses 4 ASID bits (out of the 12 available) because it assigns them per-core and recycles them aggressively. However, if you instea

I'd also strongly argue for there only being a single configuration for both virtualized and non-virtualized systems. The fewer different cases that software has to handle, the better for everyone. Th

You can achieve the same thing using the hypervisor extension analogously to how M/U systems can avoid user-level interrupts by switching to M/S/U. Instead of running the kernel in S-mode and drivers

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 reactivat

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

In the worst case, a software page table walk isn't that expensive.

Could you clarify what suggestions you think we should implement? The KAISER paper describes a way of mitigating side channel attacks, but do you have specific lessons you think we should learn from i