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

Siqi, Thanks. That narrows down where we are differing. If the hypervisor has set hideleg bit 6 (so that VS-level timer interrupts can be received by VS-mode while V=1), then any new pending

Hi Greg, I understand your concern. In fact, the goal is not to provide more than one vstimecmp CSR. You are right that when a VM is context switched out, it's vstimecmp CSR is also switched out.

Siqi, Thanks for your clarification. If I understand correctly, your goal (analogous to SGEI as you mention) is to enable a pending virtual timer interrupt, even for a VM not currently context

OK - taking a step back, what about requiring: any extension spec that doesn't specifically discuss enabling and disabling should be prohibited from enabling or disabling.. I can't see any good use

The hypervisor spec specifically says that implementations should have writable misa so this isn't theoretical: "The hypervisor extension is enabled by setting bit 7 in the misa CSR, which corresponds