summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-07-28Merge branch 'kvm-arm64/config-masks' into kvmarm/nextOliver Upton
* kvm-arm64/config-masks: : More config-driven mask computation, courtesy of Marc Zyngier : : Converts more system registers to the config-driven computation of RESx : masks based on the advertised feature set KVM: arm64: Tighten the definition of FEAT_PMUv3p9 KVM: arm64: Convert MDCR_EL2 to config-driven sanitisation KVM: arm64: Convert SCTLR_EL1 to config-driven sanitisation KVM: arm64: Convert TCR2_EL2 to config-driven sanitisation arm64: sysreg: Add THE/ASID2 controls to TCR2_ELx Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-26Merge branch 'kvm-arm64/misc' into kvmarm/nextOliver Upton
* kvm-arm64/misc: : Miscellaneous fixes/cleanups for KVM/arm64 : : - Fixes for computing POE output permissions : : - Return ENXIO for invalid VGIC device attribute : : - String helper conversions arm64: kvm: trace_handle_exit: use string choices helper arm64: kvm: sys_regs: use string choices helper KVM: arm64: Follow specification when implementing WXN KVM: arm64: Remove the wi->{e0,}poe vs wr->{p,u}ov confusion KVM: arm64: vgic-its: Return -ENXIO to invalid KVM_DEV_ARM_VGIC_GRP_CTRL attrs Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-26Merge branch 'kvm-arm64/gcie-legacy' into kvmarm/nextOliver Upton
* kvm-arm64/gcie-legacy: : Support for GICv3 emulation on GICv5, courtesy of Sascha Bischoff : : FEAT_GCIE_LEGACY adds the necessary hardware for GICv5 systems to : support the legacy GICv3 for VMs, including a backwards-compatible VGIC : implementation that we all know and love. : : As a starting point for GICv5 enablement in KVM, enable + use the : GICv3-compatible feature when running VMs on GICv5 hardware. KVM: arm64: gic-v5: Probe for GICv5 KVM: arm64: gic-v5: Support GICv3 compat arm64/sysreg: Add ICH_VCTLR_EL2 irqchip/gic-v5: Populate struct gic_kvm_info irqchip/gic-v5: Skip deactivate for forwarded PPI interrupts Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-26Merge tag 'irqchip-gic-v5-host' into kvmarm/nextOliver Upton
GICv5 initial host support Add host kernel support for the new arm64 GICv5 architecture, which is quite a departure from the previous ones. Include support for the full gamut of the architecture (interrupt routing and delivery to CPUs, wired interrupts, MSIs, and interrupt translation). * tag 'irqchip-gic-v5-host': (32 commits) arm64: smp: Fix pNMI setup after GICv5 rework arm64: Kconfig: Enable GICv5 docs: arm64: gic-v5: Document booting requirements for GICv5 irqchip/gic-v5: Add GICv5 IWB support irqchip/gic-v5: Add GICv5 ITS support irqchip/msi-lib: Add IRQ_DOMAIN_FLAG_FWNODE_PARENT handling irqchip/gic-v3: Rename GICv3 ITS MSI parent PCI/MSI: Add pci_msi_map_rid_ctlr_node() helper function of/irq: Add of_msi_xlate() helper function irqchip/gic-v5: Enable GICv5 SMP booting irqchip/gic-v5: Add GICv5 LPI/IPI support irqchip/gic-v5: Add GICv5 IRS/SPI support irqchip/gic-v5: Add GICv5 PPI support arm64: Add support for GICv5 GSB barriers arm64: smp: Support non-SGIs for IPIs arm64: cpucaps: Add GICv5 CPU interface (GCIE) capability arm64: cpucaps: Rename GICv3 CPU interface capability arm64: Disable GICv5 read/write/instruction traps arm64/sysreg: Add ICH_HFGITR_EL2 arm64/sysreg: Add ICH_HFGWTR_EL2 ... Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-26Merge branch 'kvm-arm64/doublefault2' into kvmarm/nextOliver Upton
* kvm-arm64/doublefault2: (33 commits) : NV Support for FEAT_RAS + DoubleFault2 : : Delegate the vSError context to the guest hypervisor when in a nested : state, including registers related to ESR propagation. Additionally, : catch up KVM's external abort infrastructure to the architecture, : implementing the effects of FEAT_DoubleFault2. : : This has some impact on non-nested guests, as SErrors deemed unmasked at : the time they're made pending are now immediately injected with an : emulated exception entry rather than using the VSE bit. KVM: arm64: Make RAS registers UNDEF when RAS isn't advertised KVM: arm64: Filter out HCR_EL2 bits when running in hypervisor context KVM: arm64: Check for SYSREGS_ON_CPU before accessing the CPU state KVM: arm64: Commit exceptions from KVM_SET_VCPU_EVENTS immediately KVM: arm64: selftests: Test ESR propagation for vSError injection KVM: arm64: Populate ESR_ELx.EC for emulated SError injection KVM: arm64: selftests: Catch up set_id_regs with the kernel KVM: arm64: selftests: Add SCTLR2_EL1 to get-reg-list KVM: arm64: selftests: Test SEAs are taken to SError vector when EASE=1 KVM: arm64: selftests: Add basic SError injection test KVM: arm64: Don't retire MMIO instruction w/ pending (emulated) SError KVM: arm64: Advertise support for FEAT_DoubleFault2 KVM: arm64: Advertise support for FEAT_SCTLR2 KVM: arm64: nv: Enable vSErrors when HCRX_EL2.TMEA is set KVM: arm64: nv: Honor SError routing effects of SCTLR2_ELx.NMEA KVM: arm64: nv: Take "masked" aborts to EL2 when HCRX_EL2.TMEA is set KVM: arm64: Route SEAs to the SError vector when EASE is set KVM: arm64: nv: Ensure Address size faults affect correct ESR KVM: arm64: Factor out helper for selecting exception target EL KVM: arm64: Describe SCTLR2_ELx RESx masks ... Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-26Merge branch 'kvm-arm64/cacheable-pfnmap' into kvmarm/nextOliver Upton
* kvm-arm64/cacheable-pfnmap: : Cacheable PFNMAP support at stage-2, courtesy of Ankit Agrawal : : For historical reasons, KVM only allows cacheable mappings at stage-2 : when a kernel alias exists in the direct map for the memory region. On : hardware without FEAT_S2FWB, this is necessary as KVM must do cache : maintenance to keep guest/host accesses coherent. : : This is unnecessarily restrictive on systems with FEAT_S2FWB and : CTR_EL0.DIC, as KVM no longer needs to perform cache maintenance to : maintain correctness. : : Allow cacheable mappings at stage-2 on supporting hardware when the : corresponding VMA has cacheable memory attributes and advertise a : capability to userspace such that a VMM can determine if a stage-2 : mapping can be established (e.g. VFIO device). KVM: arm64: Expose new KVM cap for cacheable PFNMAP KVM: arm64: Allow cacheable stage 2 mapping using VMA flags KVM: arm64: Block cacheable PFNMAP mapping KVM: arm64: Assume non-PFNMAP/MIXEDMAP VMAs can be mapped cacheable KVM: arm64: Rename the device variable to s2_force_noncacheable Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-23arm64: kvm: trace_handle_exit: use string choices helperKuninori Morimoto
We can use string choices helper, let's use it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87o6ti5ksx.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-23arm64: kvm: sys_regs: use string choices helperKuninori Morimoto
We can use string choices helper, let's use it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87pldy5ktb.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-23KVM: arm64: Follow specification when implementing WXNMarc Zyngier
The R_QXXPC and R_NPBXC rules have some interesting (and pretty sharp) corners when defining the behaviour of of WXN at S1: - when S1 overlay is enabled, WXN applies to the overlay and will remove W - when S1 overlay is disabled, WXN applies to the base permissions and will remove X. Today, we lumb the two together in a way that doesn't really match the rules, making things awkward to follow what is happening, in particular when overlays are enabled. Split these two rules over two distinct paths, which makes things a lot easier to read and validate against the architecture rules. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250701151648.754785-3-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-23KVM: arm64: Remove the wi->{e0,}poe vs wr->{p,u}ov confusionMarc Zyngier
Some of the POE computation is a bit confused. Specifically, there is an element of confusion between what wi->{e0,}poe an wr->{p,u}ov actually represent. - wi->{e0,}poe is an *input* to the walk, and indicates whether POE is enabled at EL0 or EL{1,2} - wr->{p,u}ov is a *result* of the walk, and indicates whether overlays are enabled. Crutially, it is possible to have POE enabled, and yet overlays disabled, while the converse isn't true What this all means is that once the base permissions have been established, checking for wi->{e0,}poe makes little sense, because the truth about overlays resides in wr->{p,u}ov. So constructs checking for (wi->poe && wr->pov) only add perplexity. Refactor compute_s1_overlay_permissions() and the way it is called according to the above principles. Take the opportunity to avoid reading registers that are not strictly required. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250701151648.754785-2-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-23KVM: arm64: vgic-its: Return -ENXIO to invalid KVM_DEV_ARM_VGIC_GRP_CTRL attrsDavid Woodhouse
A preliminary version of a hack to invoke unmap_all_vpes() from an ioctl didn't work very well. We eventually determined this was because we were invoking it on the wrong file descriptor, but not getting an error. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Eric Auger <eric.auger@redhat.com> Link: https://lore.kernel.org/r/bbbddd56135399baf699bc46ffb6e7f08d9f8c9f.camel@infradead.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-21KVM: arm64: Make RAS registers UNDEF when RAS isn't advertisedMarc Zyngier
We currently always expose FEAT_RAS when available on the host. As we are about to make this feature selectable from userspace, check for it being present before emulating register accesses as RAZ/WI, and inject an UNDEF otherwise. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250721101955.535159-4-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-21KVM: arm64: Filter out HCR_EL2 bits when running in hypervisor contextMarc Zyngier
Most HCR_EL2 bits are not supposed to affect EL2 at all, but only the guest. However, we gladly merge these bits with the host's HCR_EL2 configuration, irrespective of entering L1 or L2. This leads to some funky behaviour, such as L1 trying to inject a virtual SError for L2, and getting a taste of its own medecine. Not quite what the architecture anticipated. In the end, the only bits that matter are those we have defined as invariants, either because we've made them RESx (E2H, HCD...), or that we actively refuse to merge because the mess with KVM's own logic. Use the sanitisation infrastructure to get the RES1 bits, and let things rip in a safer way. Fixes: 04ab519bb86df ("KVM: arm64: nv: Configure HCR_EL2 for FEAT_NV2") Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250721101955.535159-3-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-21KVM: arm64: Check for SYSREGS_ON_CPU before accessing the CPU stateMarc Zyngier
Mark Brown reports that since we commit to making exceptions visible without the vcpu being loaded, the external abort selftest fails. Upon investigation, it turns out that the code that makes registers affected by an exception visible to the guest is completely broken on VHE, as we don't check whether the system registers are loaded on the CPU at this point. We managed to get away with this so far, but that's obviously as bad as it gets, Add the required checksm and document the absolute need to check for the SYSREGS_ON_CPU flag before calling into any of the __vcpu_write_sys_reg_to_cpu()__vcpu_read_sys_reg_from_cpu() helpers. Reported-by: Mark Brown <broonie@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/18535df8-e647-4643-af9a-bb780af03a70@sirena.org.uk Link: https://lore.kernel.org/r/20250720102229.179114-1-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Tighten the definition of FEAT_PMUv3p9Marc Zyngier
The current definition of FEAT_PMUv3p9 doesn't check for the lack of an IMPDEF PMU, which is encoded as 0b1111, but considered unsigned. Use the recently introduced helper to address the issue (which is harmless, as KVM never advertises an IMPDEF PMU). Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714115503.3334242-6-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Convert MDCR_EL2 to config-driven sanitisationMarc Zyngier
As for other registers, convert the determination of the RES0 bits affecting MDCR_EL2 to be driven by a table extracted from the 2025-06 JSON drop Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714115503.3334242-5-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Convert SCTLR_EL1 to config-driven sanitisationMarc Zyngier
As for other registers, convert the determination of the RES0 bits affecting SCTLR_EL1 to be driven by a table extracted from the 2025-06 JSON drop Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714115503.3334242-4-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Convert TCR2_EL2 to config-driven sanitisationMarc Zyngier
As for other registers, convert the determination of the RES0 bits affecting TCR2_EL2 to be driven by a table extracted from the 2025-06 JSON drop. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714115503.3334242-3-maz@kernel.org Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15arm64: sysreg: Add THE/ASID2 controls to TCR2_ELxMarc Zyngier
FEAT_THE and FEAT_ASID2 add new controls to the TCR2_ELx registers. Add them to the register descriptions. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250714115503.3334242-2-maz@kernel.org [ fix whitespace ] Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15KVM: arm64: Commit exceptions from KVM_SET_VCPU_EVENTS immediatelyOliver Upton
syzkaller has found that it can trip a warning in KVM's exception emulation infrastructure by repeatedly injecting exceptions into the guest. While it's unlikely that a reasonable VMM will do this, further investigation of the issue reveals that KVM can potentially discard the "pending" SEA state. While the handling of KVM_GET_VCPU_EVENTS presumes that userspace-injected SEAs are realized immediately, in reality the emulated exception entry is deferred until the next call to KVM_RUN. Hack-a-fix the immediate issues by committing the pending exceptions to the vCPU's architectural state immediately in KVM_SET_VCPU_EVENTS. This is no different to the way KVM-injected exceptions are handled in KVM_RUN where we potentially call __kvm_adjust_pc() before returning to userspace. Reported-by: syzbot+4e09b1432de3774b86ae@syzkaller.appspotmail.com Reported-by: syzbot+1f6f096afda6f4f8f565@syzkaller.appspotmail.com Reviewed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-15arm64: smp: Fix pNMI setup after GICv5 reworkMarc Zyngier
Breno reports that pNMIs are not behaving the way they should since they were reworked for GICv5. Turns out we feed the IRQ number to the pNMI helper instead of the IPI number -- not a good idea. Fix it by providing the correct number (duh). Fixes: ba1004f861d16 ("arm64: smp: Support non-SGIs for IPIs") Reported-by: Breno Leitao <leitao@debian.org> Suggested-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org>
2025-07-09KVM: arm64: selftests: Test ESR propagation for vSError injectionOliver Upton
Ensure that vSErrors taken in the guest have an appropriate ESR_ELx value for the expected exception. Additionally, switch the EASE test to install the SEA handler at the SError offset, as the ESR is still expected to match an SEA in that case. Link: https://lore.kernel.org/r/20250708230632.1954240-3-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-09KVM: arm64: Populate ESR_ELx.EC for emulated SError injectionOliver Upton
The hardware vSError injection mechanism populates ESR_ELx.EC as part of ESR propagation and the contents of VSESR_EL2 populate the ISS field. Of course, this means our emulated injection needs to set up the EC correctly for an SError too. Fixes: ce66109cec86 ("KVM: arm64: nv: Take "masked" aborts to EL2 when HCRX_EL2.TMEA is set") Link: https://lore.kernel.org/r/20250708230632.1954240-2-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: gic-v5: Probe for GICv5Sascha Bischoff
Add in a probe function for GICv5 which enables support for GICv3 guests on a GICv5 host, if FEAT_GCIE_LEGACY is supported by the hardware. Co-authored-by: Timothy Hayes <timothy.hayes@arm.com> Signed-off-by: Timothy Hayes <timothy.hayes@arm.com> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Link: https://lore.kernel.org/r/20250627100847.1022515-6-sascha.bischoff@arm.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: gic-v5: Support GICv3 compatSascha Bischoff
Add support for GICv3 compat mode (FEAT_GCIE_LEGACY) which allows a GICv5 host to run GICv3-based VMs. This change enables the VHE/nVHE/hVHE/protected modes, but does not support nested virtualization. A lazy-disable approach is taken for compat mode; it is enabled on the vgic_v3_load path but not disabled on the vgic_v3_put path. A non-GICv3 VM, i.e., one based on GICv5, is responsible for disabling compat mode on the corresponding vgic_v5_load path. Currently, GICv5 is not supported, and hence compat mode is not disabled again once it is enabled, and this function is intentionally omitted from the code. Co-authored-by: Timothy Hayes <timothy.hayes@arm.com> Signed-off-by: Timothy Hayes <timothy.hayes@arm.com> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Link: https://lore.kernel.org/r/20250627100847.1022515-5-sascha.bischoff@arm.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08arm64/sysreg: Add ICH_VCTLR_EL2Sascha Bischoff
This system register is required to enable/disable V3 legacy mode when running on a GICv5 host. Co-authored-by: Timothy Hayes <timothy.hayes@arm.com> Signed-off-by: Timothy Hayes <timothy.hayes@arm.com> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Link: https://lore.kernel.org/r/20250627100847.1022515-4-sascha.bischoff@arm.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08irqchip/gic-v5: Populate struct gic_kvm_infoSascha Bischoff
Populate the gic_kvm_info struct based on support for FEAT_GCIE_LEGACY. The struct is used by KVM to probe for a compatible GIC. Co-authored-by: Timothy Hayes <timothy.hayes@arm.com> Signed-off-by: Timothy Hayes <timothy.hayes@arm.com> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Link: https://lore.kernel.org/r/20250627100847.1022515-3-sascha.bischoff@arm.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08irqchip/gic-v5: Skip deactivate for forwarded PPI interruptsSascha Bischoff
If a PPI interrupt is forwarded to a guest, skip the deactivate and only EOI. Rely on the guest deactivating both the virtual and physical interrupts (due to ICH_LRx_EL2.HW being set) later on as part of handling the injected interrupt. This mimics the behaviour seen on native GICv3. This is part of adding support for the GICv3 compatibility mode on a GICv5 host. Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Co-authored-by: Timothy Hayes <timothy.hayes@arm.com> Signed-off-by: Timothy Hayes <timothy.hayes@arm.com> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com> Link: https://lore.kernel.org/r/20250627100847.1022515-2-sascha.bischoff@arm.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: selftests: Catch up set_id_regs with the kernelOliver Upton
Add test coverage for ID_AA64MMFR3_EL1 and the recently added FEAT_DoubleFault2. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-28-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: selftests: Add SCTLR2_EL1 to get-reg-listOliver Upton
Handle SCTLR2_EL1 specially as it is only visible to userspace when FEAT_SCTLR2 is implemented for the VM. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-27-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: selftests: Test SEAs are taken to SError vector when EASE=1Oliver Upton
Ensure KVM routes SEAs to the correct vector depending on SCTLR2_EL1.EASE. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-26-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: selftests: Add basic SError injection testOliver Upton
Add tests for SError injection considering KVM is more directly involved in delivery: - Pending SErrors are taken at the first CSE after SErrors are unmasked - Pending SErrors aren't taken and remain pending if SErrors are masked - Unmasked SErrors are taken immediately when injected (implementation detail) Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-25-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: Don't retire MMIO instruction w/ pending (emulated) SErrorOliver Upton
KVM might have an emulated SError queued for the guest if userspace returned an abort for MMIO. Better yet, it could actually be a *synchronous* exception in disguise if SCTLR2_ELx.EASE is set. Don't advance PC if KVM owes an emulated SError, just like the handling of emulated SEA injection. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-24-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: Advertise support for FEAT_DoubleFault2Oliver Upton
KVM's external abort injection now respects the exception routing wreckage due to FEAT_DoubleFault2. Advertise the feature. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-23-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: Advertise support for FEAT_SCTLR2Oliver Upton
Everything is in place to handle the additional state for SCTLR2_ELx, which is all that FEAT_SCTLR2 implies. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-22-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: nv: Enable vSErrors when HCRX_EL2.TMEA is setOliver Upton
Per R_CDCKC, vSErrors are enabled if HCRX_EL2.TMEA is set, regardless of HCR_EL2.AMO. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-21-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: nv: Honor SError routing effects of SCTLR2_ELx.NMEAOliver Upton
As the name might imply, when NMEA is set SErrors are non-maskable and can be taken regardless of PSTATE.A. As is the recurring theme with DoubleFault2, the effects on SError routing are entirely backwards to this. If at EL1, NMEA is *not* considered for SError routing when TMEA is set and the exception is taken to EL2 when PSTATE.A is set. Link: https://lore.kernel.org/r/20250708172532.1699409-20-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: nv: Take "masked" aborts to EL2 when HCRX_EL2.TMEA is setOliver Upton
HCRX_EL2.TMEA further modifies the external abort behavior where unmasked aborts are taken to EL1 and masked aborts are taken to EL2. It's rather weird when you consider that SEAs are, well, *synchronous* and therefore not actually maskable. However, for the purposes of exception routing, they're considered "masked" if the A flag is set. This gets a bit hairier when considering the fact that TMEA also enables vSErrors, i.e. KVM has delegated the HW vSError context to the guest hypervisor. We can keep the vSError context delegation as-is by taking advantage of a couple properties: - If SErrors are unmasked, the 'physical' SError can be taken in-context immediately. In other words, KVM can emulate the EL1 SError while preserving vEL2's ownership of the vSError context. - If SErrors are masked, the 'physical' SError is taken to EL2 immediately and needs the usual nested exception entry. Note that the new in-context handling has the benign effect where unmasked SError injections are emulated even for non-nested VMs. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-19-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: Route SEAs to the SError vector when EASE is setOliver Upton
One of the finest additions of FEAT_DoubleFault2 is the ability for software to request *synchronous* external aborts be taken to the SError vector, which of coure are *asynchronous* in nature. Opinions be damned, implement the architecture and send SEAs to the SError vector if EASE is set for the target context. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-18-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: nv: Ensure Address size faults affect correct ESROliver Upton
For historical reasons, Address size faults are first injected into the guest as an SEA and ESR_EL1 is subsequently modified to reflect the correct FSC. Of course, when dealing with a vEL2 this should poke ESR_EL2. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-17-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: Factor out helper for selecting exception target ELOliver Upton
Pull out the exception target selection from pend_sync_exception() for general use. Use PSR_MODE_ELxh as a shorthand for the target EL, as SP_ELx selection is handled further along in the hyp's exception emulation. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-16-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: Describe SCTLR2_ELx RESx masksOliver Upton
External abort injection will soon rely on a sanitised view of SCTLR2_ELx to determine exception routing. Compute the RESx masks. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-15-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: Enable SCTLR2 when advertised to the guestOliver Upton
HCRX_EL2.SCTLR2En needs to be set for SCTLR2_EL1 to take effect in hardware (in addition to disabling traps). Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-14-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: Context switch SCTLR2_ELx when advertised to the guestOliver Upton
Restore SCTLR2_EL1 with the correct value for the given context when FEAT_SCTLR2 is advertised to the guest. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-13-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: Wire up SCTLR2_ELx sysreg descriptorsOliver Upton
Set up the sysreg descriptors for SCTLR2_ELx, along with the associated storage and VNCR mapping. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-12-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: nv: Describe trap behavior of SCTLR2_EL1Oliver Upton
Add the complete trap description for SCTLR2_EL1, including FGT and the inverted HCRX bit. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-11-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: nv: Advertise support for FEAT_RASOliver Upton
Now that the missing bits for vSError injection/deferral have been added we can merrily claim support for FEAT_RAS. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-10-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: nv: Use guest hypervisor's vSError stateOliver Upton
When HCR_EL2.AMO is set, physical SErrors are routed to EL2 and virtual SError injection is enabled for EL1. Conceptually treating host-initiated SErrors as 'physical', this means we can delegate control of the vSError injection context to the guest hypervisor when nesting && AMO is set. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-9-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: nv: Add FEAT_RAS vSError sys regs to tableOliver Upton
Prepare to implement RAS for NV by adding the missing EL2 sysregs for the vSError context. Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-8-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2025-07-08KVM: arm64: nv: Honor SError exception routing / maskingOliver Upton
To date KVM has used HCR_EL2.VSE to track the state of a pending SError for the guest. With this bit set, hardware respects the EL1 exception routing / masking rules and injects the vSError when appropriate. This isn't correct for NV guests as hardware is oblivious to vEL2's intentions for SErrors. Better yet, with FEAT_NV2 the guest can change the routing behind our back as HCR_EL2 is redirected to memory. Cope with this mess by: - Using a flag (instead of HCR_EL2.VSE) to track the pending SError state when SErrors are unconditionally masked for the current context - Resampling the routing / masking of a pending SError on every guest entry/exit - Emulating exception entry when SError routing implies a translation regime change Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20250708172532.1699409-7-oliver.upton@linux.dev Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
generated by cgit (git 2.34.1) at 2025-09-27 08:43:22 +0000