In other architectures, those devices are needlessly complex in part because they weren’t co-designed with the ISA. Yes, they can be independently designed, but possibly with regrettable consequences.

On Tue, Feb 2, 2021 at 8:06 PM Anup Patel <Anup.Patel@...> wrote:

On all major architectures (x86 and ARM64), the virtualization-aware interrupt controllers and IOMMUs are totally independent from ISA virtualization support.

 

We already the required ISA support in H-extension for virtualization-aware interrupt controller.

 

The IOMMUs are totally independent of CPU virtualization support on all major architectures and I don’t see how H-extension need to change for IOMMU support.

 

Regards,

Anup

 

From: Andrew Waterman <andrew@...>


Sent: 03 February 2021 09:24


To: Anup Patel <Anup.Patel@...>


Cc: Alistair Francis <Alistair.Francis@...>; Allen Baum <allen.baum@...>; Atish Patra <Atish.Patra@...>; Greg Favor <gfavor@...>; John Hauser <jh.riscv@...>; Krste Asanovic <krste@...>; tech-privileged@...;

tech-unixplatformspec@...


Subject: Re: RISC-V H-extension freeze consideration

 

I’m not in support of freezing it yet. My concern is that development of virtualization-aware interrupt controllers and IOMMUs will lead to reconsideration of some of the details. All of these items are logically interlocking, even if physically

disjoint separate. It’s entirely possible that we will make no changes as a result of that further development, but it’s far from certain.

 

Furthermore, the hypervisor extension is of substantially greater with those other items completed, so we aren’t losing out as much as it might seem by postponing the freeze.

 

On Tue, Feb 2, 2021 at 7:47 PM Anup Patel <Anup.Patel@...> wrote:

Hi All,











The RISC-V H-extension v0.6.1 draft was released almost a year back in





May 2020. There has been no changes in the H-extension specification





since then.











Meanwhile, we have RISC-V H-extension v0.6.1 implemented in QEMU,





Spike, and Rocket FPGA. We also have three different hypervisors ported





to RISC-V H-extension v0.6.1:





1. Xvisor RISC-V (Works on QEMU, Spike, and Rocket FPGA)





2. KVM RISC-V (Works on QEMU, Spike and Rocket FPGA)





3. Bao (Works on Rocket FPGA)











Unfortunately, RISC-V H-extension not being in freeze state is now gating





further software development because major open source projects (such





as Linux RISC-V and GCC RISC-V) have adopted a policy of accepting patches





only for frozen or ratified RISC-V extensions.











Few examples of gated software development:





1. KVM RISC-V not merged in upstream Linux RISC-V. The KVM RISC-V





    patches are already reviewed and acked by maintainers in July 2019.





    Currently, we are rebasing KVM RISC-V patches with every kernel





    release since 1.5+ years.





2. GCC RISC-V not accepting patches for H-extension related instructions





3. KVMTOOL RISC-V not merged because KVM RISC-V is not merged in





    upstream Linux RISC-V





4. QEMU KVM RISC-V acceleration not merged because KVM RISC-V is





    not merged in upstream Linux RISC-V





5. Various feature additions (such as SBI v0.2, nested, etc) can't happen





   (or can't be merged) until KVM RISC-V is merged in Linux RISC-V





6. Libvirt library blocked on QEMU KVM RISC-V acceleration being





    available. The Libvirt library is a crucial piece in open-source cloud





    solutions (such as open-stack).





7. As time passes more items (such as KVM RISC-V AIA support) will





    get blocked if KVM RISC-V is not merged upstream.











We would request the TSC to consider freezing RISC-V H-extension v0.6.1





draft specification. Remaining items in done checklist for ratification can





certainly be completed while H-extension is in the frozen state.











Best Regards,





Anup Patel