If GEILEN is zero then there are no guest external interrupts but software (i.e. hypervisor) can still inject external interrupts using hvip CSR. In other words, software-injected external interrupts

On 29/10/21, 5:19 AM, "tech-privileged@... on behalf of Vedvyas Shanbhogue" <tech-privileged@... on behalf of ved@...> wrote: I do not think it avoids the issue but wo

+Mark This is really awesome !!! The proposed IOMMU specification is quite feature rich and at-par with IOMMUs found on other major architectures. This will certainly be a big addition to the collecti

Hi All, The KVM RISC-V AIA support has been successfully validated with AIA IMSIC virtualization features emulated by QEMU RISC-V. This means KVM RISC-V Guest Linux works perfectly fine with Guest VCP

Generic booting flow on ARM for rich-OS capable SoC looks like this: BootROM => Loader => Runtime => Bootloader => RichOS (EL3) (EL1S) (EL3) (EL2 or EL1NS) (EL2 or EL1NS) (ATF BL1) (ATF BL2) (ATF BL31

(Adding other platform HSC folks) On 03/08/21, 10:10 PM, "Nick Kossifidis" <mick@...> wrote: Στις 2021-07-27 10:16, Andrew Waterman έγραψε: (ccing Anup/Atish) Good point, BootROM is hw-speci

+John Hause From: <tech-privileged@...> on behalf of Richard Trauben <rtrauben@...> Date: Monday, 12 July 2021 at 11:15 AM To: Richard Trauben <rtrauben@...> Cc: Anup Patel <An

Hi Paolo, On 12/07/21, 4:42 PM, "tech-virt-mem@... on behalf of Paolo Bonzini" <tech-virt-mem@... on behalf of pbonzini@...> wrote: Why wouldn't this actually be taken

I agree with Jonathan. To add more information: Any wrong memory access done by Guest/VM (VS-level) via explicit load/store instruction or via VS-stage page table walk will result in Guest page fault

Most hypervisor will always have G-stage (Stage2) programmed for each Guest/VM irrespective whether VS-mode MMU is on or off. This means the G-stage level protection is always there for Guest/VM. When

H-extension is already considered in this proposal. We have filter bits for VS/VU modes only events. Linux PMU driver will using SBI PMU extension. The SBI PMU extension will be implemented in platfor

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-

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

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 Hyper

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) (Already

Hi Chuanhua, Even if we ignore the RISC-V CSR range violation in allowing writes to HPMCOUNTER CSR from S-mode, still the “bypass-sbi” DT property is not an acceptable solution. The “bypass-sbi” DT pr

Hi Chuanhua, The fact that “write-enable” bit in HPMEVENT CSR makes corresponding HPMCOUNTER as writeable violates the RISC-V CSR numbering scheme of RISC-V privilege spec because it allows S-mode wri

Hi Alan, Like mentioned previously, having different mechanism for HS-mode and VS-mode to write HPMCOUNTER CSR is not acceptable. The “bypass-sbi” DT property only means that Linux PMU driver is now a

Hi Alan, Thanks for the data points. The proposed SBI_PMU_COUNTER_CONFIG_MATCHING will helps us minimize SBI calls for configuring HPMEVENT CSR. I am not sure if you have considered latest SBI PMU ext