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

OK, we had a closer look at the N extension, and it doesn’t do much for us, should have looked closer in the first place :-( Hence I don’t particularly care about this one – sorry for the

Gernot wrote: Aside from the fact that doing this requires some version of the quasi-deprecated N extension be implemented in addition to the hypervisor extension, the main problem with this idea is

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

On 2020-09-19 5:29 a.m., Gernot wrote: I don't know if these developments will address your concerns, but I see the synergy of these two task groups, Fast-interrupts and Code Size

On 19 Sep 2020, at 15:53, Andrew Waterman <andrew@...> wrote: That’s a real concern, and I seem to have missed any discussion about this. I suspect that this also reflects a confusion resulting from

The N extension is effectively deprecated. We don’t see sufficient demand for user-level interrupts in managed/Unix-like environments to pursue that approach at this time. We do see demand for this

Hi, The context switching overhead for VirtIO interrupts that this proposal is trying to solve is already solved across architectures by: KVM in-kernel VirtIO backends emulation (i.e. VHost)

If I understand correctly, there is a security issue around the URET instruction. All the controls for URET are accessible from User mode. This is OK in the scenario you describe where U-Mode is

Hi all, When we applied user-level interrupts in N extension to the Unix-like OS, there is no way to directly handle user-level interrupts in userspace bypassing the kernel. This makes little use

Hi all, In this proposal, we extended N extension and applied it to H extension for improving the performance of virtual I/O devices in the virtualization scenario. We proposed a new mechanism to

Yes, the behavior you'd like follows implicitly from the definition of mideleg.

Hi, The definition of the interrupt pending and enable registers, example mip and mie, define bits 16 and above as available for platform or custom use. Section 3.1.9 Machine Interrupt Registers (mip

Emulating systems that don’t support some extension either has SW that doesn’t use the extension, in which case it does t matter if the extension is enabled or disable, or does use it, in which

Emulating less-capable systems.

zhaosiqi (Siqi) wrote: I believe a hypervisor can get the same effect by saving and clearing bit 6 of hideleg on entry to a trap handler in HS mode. On trap exit, restore the saved value of bit 6 of