linux.git/arch/riscv, branch master

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm

2026-07-21T15:26:21+00:00

Pull kvm fixes from Paolo Bonzini:
 "RISC-V:

   - Avoid redundant allocations when allocating IMSIC page tables

   - Apply SBI FWFT LOCK flag only on successful set

   - Bound SBI PMU counter mask scan to BITS_PER_LONG, since on RV32 the
     PMU SBI start/stop helper can only access 32 PMU counters.

   - Skip TLB flush when G-stage PTE becomes valid if the Svvptc
     extension is available.

   - Always show Zicbo[m|z|p] block sizes in ONE_REG

   - Inject instruction access fault on unmapped guest fetch

   - Use raw spinlock for irqs_pending and irqs_pending_mask

   - Fix Spectre-v1 in vector register access via ONE_REG

  x86:

   - Fixes to SEV selftests

   - Once free_nested() did a VMCLEAR of shadow VMCS, there's no need to
     VMCLEAR it again if the kernel is preempted and thread migration
     happens

   - Preserve nested TDP shadow page tables if they are used as roots,
     instead of clearing them unnecessarily

   - Fix use of stale data if out-of-memory happens after vendor module
     reload

   - Check for invalid/obsolete root *after* making MMU pages available,
     because the latter can make a page invalid

   - Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN
  KVM: selftests: sev_init2_tests: Derive SEV availability from KVM
  KVM: selftests: sev_smoke_test: Only run VM types the host offers
  KVM: x86/mmu: Fix use-after-free on vendor module reload
  KVM: x86/mmu: Preserve nested TDP shadow page tables if they are used as roots
  KVM: x86: Check for invalid/obsolete root *after* making MMU pages available
  KVM: nVMX: Hide shadow VMCS right after VMCLEAR
  KVM: riscv: Fix Spectre-v1 in vector register access
  RISC-V: KVM: Serialize virtual interrupt pending state updates
  RISC-V: KVM: Inject instruction access fault on unmapped guest fetch
  RISC-V: KVM: Zicbo[m|z|p] block sizes should be always present in ONE_REG
  riscv: kvm: Skip TLB flush when G-stage PTE becomes valid with Svvptc
  KVM: riscv: PMU: Bound counter mask scan to BITS_PER_LONG
  KVM: riscv: SBI FWFT: Apply LOCK flag only on successful set
  RISC-V: KVM: Avoid redundant page-table allocations in ioremap topup

riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()

2026-07-15T17:12:40+00:00

When cpusetsize < cpumask_size(), hwprobe_get_cpus() did not fully
initialize its copy of the cpu mask, which could cause non-deterministic
results from the riscv_hwprobe syscall on a system with more than 8 CPUs
when the supplied cpu mask is empty.  Address this by fully initializing
the cpu mask.

Fixes: e178bf146e4b ("RISC-V: hwprobe: Introduce which-cpus flag")
Signed-off-by: Mark Harris 
Reviewed-by: Nam Cao 
Reviewed-by: Michael Ellerman 
Link: https://patch.msgid.link/20260714003056.73707-1-mark.hsj@gmail.com
Signed-off-by: Paul Walmsley

KVM: riscv: Fix Spectre-v1 in vector register access

2026-07-15T12:36:16+00:00

User-controlled register indices from the ONE_REG ioctl are used to
index into the vector register buffer (v0..v31). Sanitize the calculated
offset with array_index_nospec() to prevent speculative out-of-bounds
access.

Signed-off-by: Zongmin Zhou 
Reviewed-by: Anup Patel 
Link: https://lore.kernel.org/r/20260715030818.75657-1-min_halo@163.com
Signed-off-by: Anup Patel

RISC-V: KVM: Serialize virtual interrupt pending state updates

2026-07-15T08:07:48+00:00

KVM RISC-V tracks guest local interrupt state with two bitmaps:

  - irqs_pending: interrupts that should be visible to the guest
  - irqs_pending_mask: interrupts whose pending state changed

The current code updates those bitmaps with independent atomic bitops
and assumes a multiple-producer, single-consumer protocol. That model
does not actually hold.

kvm_riscv_vcpu_sync_interrupts() is not a pure consumer. When the guest
changes guest-visible HVIP state, sync_interrupts() writes both
irqs_pending and irqs_pending_mask to reflect the new guest state back
into KVM state. As a result, irqs_pending and irqs_pending_mask form a
single logical state transition, but they are not updated atomically as
a pair.

This allows a race where a newly injected interrupt is lost. For
example:

  CPU0                              CPU1
  ----                              ----
  kvm_riscv_vcpu_set_interrupt(VS_SOFT)
    set_bit(VS_SOFT, irqs_pending)
                                    kvm_riscv_vcpu_sync_interrupts()
                                      sees guest-cleared HVIP.VSSIP
                                      sets irqs_pending_mask
                                      clear_bit(IRQ_VS_SOFT, irqs_pending)
    set_bit(VS_SOFT, irqs_pending_mask)
    kvm_vcpu_kick()

After that interleaving, a later flush can update HVIP without VSSIP
even though a new virtual interrupt was injected. In practice, the
guest can remain blocked in WFI with work pending.

The same pending/mask protocol is shared by VS soft interrupts, PMU
overflow delivery, and AIA high interrupt synchronization, so the race
is not limited to one interrupt source.

Fix this by serializing all updates to irqs_pending and irqs_pending_mask
with a per-vCPU raw spinlock. This keeps the pending bit and the dirty
mask as one state transition across:

  - set/unset interrupt
  - guest HVIP sync
  - interrupt flush to guest CSR state
  - vCPU reset
  - AIA CSR writes that clear dirty state

Use non-atomic bitmap operations while holding the lock. Hold the lock
across the AIA sync, flush, and pending checks as well, so both bitmap
words share the same serialization domain.

This intentionally replaces the existing lockless protocol instead of
trying to repair it with additional barriers. The problem is not memory
ordering on a single field; it is that two separate bitmaps encode one
shared state machine while both producers and sync paths can modify
them. A per-vCPU raw spinlock keeps the fix small, local, and suitable
for backporting.

Fixes: cce69aff689e ("RISC-V: KVM: Implement VCPU interrupts and requests handling")
Cc: stable@vger.kernel.org
Signed-off-by: Xie Bo 
Reviewed-by: Anup Patel 
Link: https://lore.kernel.org/r/20260715020359.1521354-2-xb@ultrarisc.com
Signed-off-by: Anup Patel

arch/riscv: vdso: remove CFI landing pad from rt_sigreturn

2026-07-15T01:34:38+00:00

When CONFIG_RISCV_USER_CFI is enabled, the CFI version of the vDSO, has
a CFI landing pad instruction at the start of __vdso_rt_sigreturn. This
breaks libgcc's unwinding code which matches on the first two
instructions. Other unwinders that rely on similar instruction matching
may also be affected.

Since __vdso_rt_sigreturn is reached as part of signal-return handling
rather than via an indirect call/jump from userspace, it does not need a
CFI landing pad. Remove it and restore the instruction sequence expected
by existing unwinding code.

This matches what was done on arm64 in commit 9a964285572b ("arm64:
vdso: Don't prefix sigreturn trampoline with a BTI C instruction") for a
similar issue.

Cc: stable@vger.kernel.org
Fixes: 37f57bd3faea ("arch/riscv: compile vdso with landing pad and shadow stack note")
Co-authored-by: Joel Stanley 
Signed-off-by: Aurelien Jarno 
Signed-off-by: Joel Stanley 
Link: https://patch.msgid.link/20260623204058.498120-1-aurelien@aurel32.net
[pjw@kernel.org: fixed comment style]
Signed-off-by: Paul Walmsley

RISC-V: KVM: Inject instruction access fault on unmapped guest fetch

2026-07-14T13:01:51+00:00

When an instruction guest-page-fault targets a GPA that is not backed
by any memslot, KVM has no MMIO emulation path for the fetch. Load and
store guest-page faults can be routed through MMIO emulation, but an
instruction fetch has no data payload or access size for userspace to
complete in the same way.

Treat this case as an architectural access fault in the guest. On bare
metal, fetching from an inaccessible physical address raises an
instruction access fault for the supervisor to handle through its trap
vector. Reflect EXC_INST_ACCESS back to the guest so the guest observes
the same class of exception rather than leaving the fetch as a
host-handled condition.

stval contains the virtual address of the portion of the instruction that
caused the fault, while sepc points to the beginning of the instruction.

Signed-off-by: Qingwei Hu 
Reviewed-by: Anup Patel 
Link: https://lore.kernel.org/r/20260707122548.281685-1-qingwei.hu@bytedance.com
Signed-off-by: Anup Patel

riscv: vdso: Do not use LTO for the vDSO

2026-07-13T18:08:27+00:00

With LTO enabled the compiler assumes that the vDSO functions are not
used and optimizes them away completely. Currently this happens to
__vdso_clock_getres(), __vdso_clock_gettime(), __vdso_getrandom(),
__vdso_gettimeofday() and __vdso_riscv_hwprobe().

Disable LTO for the vDSO, as these functions are hand-optimized anyways.

Reported-by: kernel test robot 
Closes: https://lore.kernel.org/oe-kbuild-all/202606301855.WvkSC4kD-lkp@intel.com/
Fixes: 021d23428bdb ("RISC-V: build: Allow LTO to be selected")
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Weißschuh 
Link: https://patch.msgid.link/20260701-riscv-vdso-lto-v1-1-89db0cd82077@linutronix.de
Signed-off-by: Paul Walmsley

riscv: io: avoid null-pointer arithmetic in PIO helpers

2026-07-13T18:01:49+00:00

When port I/O is not supported, exposing the port-string helpers is both
unnecessary and can make clang diagnose null-pointer arithmetic from the
PCI_IOBASE based address expression.  Keep the MMIO string helpers
available as before, but only provide the port I/O variants when
CONFIG_HAS_IOPORT is enabled.

Signed-off-by: Yunhui Cui 
Reviewed-by: Arnd Bergmann 
Link: https://patch.msgid.link/20260703122832.15984-2-cuiyunhui@bytedance.com
Signed-off-by: Paul Walmsley

riscv: Gate FUNCTION_ALIGNMENT_4B on DYNAMIC_FTRACE

2026-07-13T17:38:56+00:00

The FUNCTION_ALIGNMENT_4B select forces the whole kernel to be built
with -fmin-function-alignment=4. This alignment is only needed so the
patchable-function-entry NOPs, which arch/riscv/Makefile emits under
CONFIG_DYNAMIC_FTRACE, can be patched reliably on RISCV_ISA_C=y builds
where compressed instructions otherwise allow 2-byte function
alignment.

The select is currently gated on HAVE_DYNAMIC_FTRACE, a capability bit
that is selected whenever the toolchain supports dynamic ftrace, rather
than on whether tracing is actually enabled. As a result every
RISCV_ISA_C=y build gets 4-byte function alignment across the entire
kernel even when function tracing is disabled, needlessly growing the
kernel image and wasting instruction cache for a feature that is not
in use.

Gate the select on DYNAMIC_FTRACE instead, matching the condition under
which arch/riscv/Makefile emits -fpatchable-function-entry, so the
alignment is only applied when it is actually needed.

Fixes: c41bf4326c7b ("riscv: ftrace: align patchable functions to 4 Byte boundary")
Signed-off-by: Rui Qi 
Link: https://patch.msgid.link/20260706130415.463682-1-qirui.001@bytedance.com
Signed-off-by: Paul Walmsley

mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap

2026-07-13T17:29:52+00:00

section_activate() does not flush TLB after populating new vmemmap
pages. On most architectures, this is okay. However it is a problem on
RISC-V since there the TLB caching non-present entries is permitted,
which causes spurious faults on some hardwares.

This seems to be most easily reproduced with DEBUG_VM=y and
PAGE_POISONING=y, which causes these newly mapped struct pages to be
poisoned i.e. written to immediately after mapping.

Extend the RISC-V flush_cache_vmap() to also handle the vmemmap range,
and call it after hotplugging vmemmap, which gets the possible spurious
fault handled in the exception handler.

At least for now, the only other architecture with both
SPARSEMEM_VMEMMAP and flush_cache_vmap() is PowerPC, which has a similar
problem with newly valid PTEs. But there flush_cache_vmap() is just a
ptesync. So it should be safe to do this for generic code while having
minimal performance impact.

Suggested-by: Muchun Song 
Signed-off-by: Vivian Wang 
Reviewed-by: Muchun Song 
Acked-by: David Hildenbrand (Arm) 
Link: https://patch.msgid.link/20260713-mark-after-vmemmap-populate-v6-2-b945ceba29d4@iscas.ac.cn
Signed-off-by: Paul Walmsley