| Age | Commit message (Collapse) | Author |
|---|
|
Since guest kernel and ioctl() parameter from user mode is untrusted,
there may be noise kernel log output in host hypervisor with abnormal
state. Here replace kvm_err() with kvm_pr_unimpl() to reduce this kind
of noise kernel log, and there is no function change.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
API kvm_vcpu_ioctl_interrupt() is mainly to used to deliver interrupt
from user mode, and internal APIs kvm_queue_irq() and kvm_dequeue_irq()
are used in kernel mode.
Also move IPI inject and ack within lock protection to avoid contention
in ipi_set() and ipi_clear().
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Variable vector[] is declared on stack in function dmsintc_inject_irq()
and sometimes it is used without initialized. Here fix this issue.
Cc: stable@vger.kernel.org
Fixes: 03de5eecb0f0 ("LoongArch: KVM: Add DMSINTC inject msi to vCPU")
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
When IPI address is not aligned with its access size, it should return
directly in read/write operations, rather than only print a message with
WARN_ON_ONCE(). The method is the same with in kernel EIOINTC and PCHPIC
operations.
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
With IOCSR instruction emulation in function kvm_emu_iocsr(), possible
size combination is 1/2/4/8 and no other combinations. Here remove the
old default case and replace the default case with 8 in read_mailbox()
and write_mailbox().
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
In function kvm_make_vcpu_request(), it will send IPI to physical CPU
when vCPU is in IN_GUEST_MODE mode. And physical CPU is set in function
kvm_check_vpid(), thus it should be called before IN_GUEST_MODE is set.
Otherwise IPI will send to wrong old physical CPU where vCPU is running.
Cc: stable@vger.kernel.org
Fixes: 2fc3bd86db4b ("LoongArch: KVM: Implement basic vcpu interfaces")
Signed-off-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
In the in-kernel MMIO read fast path of kvm_emu_mmio_read(),
kvm_complete_mmio_read() already advances the guest PC via update_pc().
The explicit update_pc() call right after it advances the PC a second
time, so PC moves forward by 8 bytes instead of 4, and the instruction
following the MMIO read is silently skipped.
The user space MMIO read completion path in kvm_arch_vcpu_ioctl_run()
calls kvm_complete_mmio_read() only once, and the MMIO write fast path
advances the PC exactly once as well.
Here remove the redundant update_pc() so the kernel MMIO read fast path
advances the PC by a single instruction.
Cc: stable@vger.kernel.org
Fixes: 80edf90831a2 ("LoongArch: KVM: Add sign extension with kernel MMIO read emulation")
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Zeng Chi <zengchi@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
A guest can write CSR.TCFG with the periodic bit set but a period value
of zero. When kvm_restore_timer() later enters the periodic branch,
period = cfg & CSR_TCFG_VAL evaluates to 0, causing (delta % period) to
trigger a division by zero and crash the host kernel.
Clamp the period to 1 to avoid the panic.
Fixes: a5857b9ff6e0 ("LoongArch: KVM: Implement vcpu timer operations")
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
kvm_restore_timer() rebuilds the remaining timer countdown value from
vcpu->arch.expire, which is host-internal and is not part of the
migrated vCPU state. On the migration destination it is still 0, so for
a one-shot timer that has not expired yet the computed delta is 0 and
write_gcsr_timertick(0) injects the timer interrupt immediately instead
of after the remaining time.
The expired one-shot case (TVAL = -1) is already handled earlier. When
expire has not been set (i.e. on the migration destination), reload the
remaining countdown value from the migrated TVAL. This covers both one-
shot and periodic timers. The regular preempt/resume path on the source,
where expire is valid, is unchanged.
Fixes: a5857b9ff6e0 ("LoongArch: KVM: Implement vcpu timer operations")
Suggested-by: Bibo Mao <maobibo@loongson.cn>
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
Several LoongArch KVM features are fully implemented but were never
reported through their standard KVM_CHECK_EXTENSION probes, so userspace
cannot discover them. Advertise the ones that already work so as to have
a real consumer:
- KVM_CAP_VCPU_ATTRIBUTES: per-vCPU device-attribute ioctls are
implemented (CPUCFG, PVTIME control); advertise the discovery cap.
- KVM_CAP_STEAL_TIME: steal time works end-to-end (host-side record
plus guest-side paravirt), the probe returns kvm_pvtime_supported().
This doesn't add new functionalities; it only makes existing features
discoverable via the standard probe.
Reviewed-by: Bibo Mao <maobibo@loongson.cn>
Signed-off-by: Tao Cui <cuitao@kylinos.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
|
|
We need the driver-core fixes in here as well to build on top of.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
|
Currently, when booting a compatibility-mode KVM guest (L1) on a PowerNV
hypervisor (L0), the guest runs with the expected processor
compatibility level. However, when booting a nested KVM guest (L2)
inside the L1, QEMU derives the CPU model from the raw host PVR and
attempts to run the nested guest at that level, instead of honoring the
compatibility mode of the L1.
Extend host CPU compatibility capability reporting to support nested
virtualization on PowerNV systems (PAPR nested API v1).
For nested API v2 (PowerVM), compatibility capabilities are served from
the cached nested_capabilities value (populated at module init via
kvmhv_nested_init() using the H_GUEST_GET_CAPABILITIES hcall). This
information is not available on PowerNV systems.
For nested API v1, derive the compatibility capabilities from the L1
guest by reading the "cpu-version" property from the device tree, which
reflects the effective (logical) processor compatibility level. Map this
value to the corresponding compatibility capability bitmap using
KVM-specific constants.
The mapping is cumulative: a system running at a given compatibility
level is assumed to also support older generations down the supported
chain. Note that unlike KVM on PowerVM (nested API v2), KVM on PowerNV
currently does not strictly enforce older generation compatibility modes
for nested guests - the reported capabilities reflect what the host CPU
can present, not what the hypervisor independently validates.
Introduce a helper kvmppc_map_compat_capabilities() to translate CPU
version values into KVM_PPC_COMPAT_CAP bits using a fallthrough switch,
and integrate it into kvmppc_get_compat_caps(). The implementation
applies masking to ensure only supported processor modes are exposed.
This allows userspace to query host CPU compatibility modes on both
KVM on PowerVM and on PowerNV platforms via the KVM_PPC_GET_COMPAT_CAPS
ioctl.
Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Tested-by: Gautam Menghani <gautam@linux.ibm.com>
Reviewed-by: Gautam Menghani <gautam@linux.ibm.com>
Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260808161148.66673-4-amachhiw@linux.ibm.com
|
|
PowerVM
On POWER systems, the host CPU may run in a compatibility mode (e.g., a
Power11 processor operating in Power10 compatibility mode). In such
cases, the effective CPU level exposed to guests differs from the
physical processor generation.
When running nested KVM guests, QEMU derives the host CPU type using
mfpvr(), which reflects the physical processor version. This can result
in a mismatch between the CPU model selected by QEMU and the
compatibility mode enforced by the host, leading to guest boot failures.
For example, booting a nested guest on a Power11 LPAR configured in
Power10 compatibility mode fails with:
KVM-NESTEDv2: couldn't set guest wide elements
[..KVM reg dump..]
This occurs because QEMU selects a CPU model corresponding to the
physical processor (via mfpvr()), while the host operates in a lower
compatibility mode. As a result, KVM rejects the requested compatibility
level during guest initialization.
On pseries nestedv2 systems, add support for retrieving host CPU
compatibility capabilities for nested guests on PowerVM. The capability
bitmap reflects the processor modes negotiated between the Power
hypervisor (L0) and the host partition (L1) via the
H_GUEST_GET_CAPABILITIES hcall, but is retrieved from the cached
nested_capabilities value populated during module initialization,
avoiding repeated hypervisor calls. A WARN_ON_ONCE() flags the
unexpected case where nested_capabilities is zero on a nestedv2 system.
The implementation defines KVM-specific capability constants
(KVM_PPC_COMPAT_CAP_POWER9/10/11), masks unsupported bits, and exposes
the result through the KVM_PPC_GET_COMPAT_CAPS ioctl.
Hook the implementation into the Book3S HV kvmppc_ops so that it can be
invoked by the generic KVM ioctl handling code.
Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Tested-by: Gautam Menghani <gautam@linux.ibm.com>
Reviewed-by: Gautam Menghani <gautam@linux.ibm.com>
Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260808161148.66673-3-amachhiw@linux.ibm.com
|
|
Introduce a new capability and ioctl to expose CPU compatibility modes
supported by the host processor for nested guests.
On IBM POWER systems, newer processor generations (N) can operate in
compatibility modes corresponding to earlier generations, like (N-1) and
(N-2). This is particularly relevant for nested virtualization, where
nested KVM guests may need to run with a specific processor compatibility
level.
Introduce KVM_CAP_PPC_COMPAT_CAPS capability and the corresponding
KVM_PPC_GET_COMPAT_CAPS vm ioctl. The ioctl returns a bitmap describing
the compatibility modes supported by the host in respective bit numbers,
allowing userspace (e.g., QEMU) to select an appropriate compatibility
level when configuring nested KVM guests.
The ioctl handling is added in kvm_arch_vm_ioctl() and retrieves host
CPU compatibility capabilities via a PowerPC-specific backend
implementation when available.
The struct kvm_ppc_compat_caps places the 'size' field first so it can
be read alone via get_user() before copy_struct_from_user() is called,
avoiding pointer arithmetic to locate the size field.
The ioctl is defined using _IO so the ioctl number remains stable even if
the struct grows in future versions. It uses copy_struct_from_user() and
copy_struct_to_user() to provide forward- and backward-compatible
extensibility: older userspace passing a smaller struct to a newer kernel
gets zero-padded trailing fields. Newer userspace passing a larger struct to
an older kernel (usize > ksize) succeeds if trailing bytes are zero (the
kernel reports back min(usize, ksize) as the filled size); if trailing bytes
are non-zero, the kernel writes back ksize into host_caps.size and returns
-E2BIG so userspace can retry with the correct size.
KVM_PPC_COMPAT_CAPS_SIZE_VER0 is defined as a frozen integer constant
(24) marking the size of the initial struct version, used as the
minimum floor for size field validation, similar to other versioned
struct interfaces in the kernel.
The 'flags' field is reserved for future use. The kernel rejects any
call where flags is non-zero with -EINVAL, preventing garbage values
from being baked into ABI permanently.
The ioctl returns appropriate error codes: E2BIG if usize exceeds
PAGE_SIZE, or if new userspace provides a larger struct with non-zero
trailing bytes (with ksize written back into host_caps.size for the
retry); EINVAL for an invalid size or non-zero reserved fields; EFAULT
for failed copy operations; and ENOTTY if the backend doesn't implement
get_compat_caps.
Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Tested-by: Gautam Menghani <gautam@linux.ibm.com>
Reviewed-by: Gautam Menghani <gautam@linux.ibm.com>
Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260808161148.66673-2-amachhiw@linux.ibm.com
|
|
Move the ppc4xx gpio driver out of arch/powerpc/platforms/44x/ into
drivers/gpio/gpio-ppc44x.c. The driver has no architecture-specific
dependencies and follows the same pattern as other PowerPC GPIO
drivers already in drivers/gpio/ (e.g. gpio-mpc8xxx, gpio-mpc5200).
- Renamed Kconfig symbol from PPC4xx_GPIO to GPIO_PPC44X
- Updated ppc44x_defconfig and warp_defconfig to use the new symbol
- Marked the new option as tristate (was bool) since the driver
supports module build via module_platform_driver()
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260803223539.86303-2-rosenp@gmail.com
|
|
The ahci-mvebu driver and libahci_platform request three supplies
on SATA controller and port nodes:
- ahci-supply (controller power)
- phy-supply (PHY power)
- target-supply (disk power per port)
Without them the regulator core prints notices at boot, e.g.:
supply ahci not found, using dummy regulator
supply phy not found, using dummy regulator
supply target not found, using dummy regulator
The SATA controller and PHY inside the Armada 388 SoC are powered
by the 3.3V I/O rail; the four disk bays are powered by the 5V HDD
rail. Wire the existing fixed regulators accordingly.
Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
The pca953x driver requests a 'vcc' supply, producing:
pca953x 0-0020: supply vcc not found, using dummy regulator
The PCA9655 (PCA9555-compatible) expander is powered by the same
always-on 3.3V rail as the other I2C devices on the bus. Add
vcc-supply = <®_3p3v> to silence the warning.
Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
The at24 driver requests a 'vcc' supply for the EEPROM, producing
'supply vcc not found, using dummy regulator' at boot when the
property is missing.
The EEPROM sits on the Helios 4 and is powered by the
same always-on 3.3V rail used by other on-board I2C devices.
Add vcc-supply = <®_3p3v> to silence the warning.
Fixes: ced8025b569e ("ARM: dts: armada388-helios4")
Assisted-by: opencode:big-pickle
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
After commit 00e6d608fe80b0f6 ("arm64: dts: marvell: armada-37xx: swap
PHYs' order in USB3 controller node") swapped USB3 PHY order, USB
initialization breaks on Turris MOX.
This regression was exposed by commit 91ddf6f722084383 ("phy: marvell:
mvebu-a3700-utmi: fix incorrect USB2_PHY_CTRL register access") which
made USB2 devices not work at all.
Fix the issue by explicitly adding all USB3 PHYs and PHY names to
Turris MOX device-tree.
Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox")
Signed-off-by: Tomáš Macholda <tomas.macholda@nic.cz>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into soc/dt
arm64: tegra: Device tree changes for v7.3-rc1
This contains a new device tree for the Lenove ThinkEdge SE70 Edge
Client device as well as a number of fixes and cleanups for Tegra234 and
Tegra194. Tegra264 sees a number of additions to enable more features.
* tag 'tegra-for-7.3-arm64-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: (1469 commits)
arm64: tegra: Correct Tegra234 p3740 interrupt flags
arm64: tegra: Correct Tegra234 p3737 interrupt flags
arm64: tegra: Correct Tegra194 p2972 interrupt flags
arm64: tegra: Drop CPU masks from GICv3 PPI interrupts
arm64: tegra: Add Lenovo ThinkEdge SE70 device tree
arm64: tegra: Add pinctrl nodes for Tegra264
arm64: tegra: Fix CMDQV interrupt type on Tegra264
arm64: tegra: Properly sort devices on Tegra264
arm64: tegra: Add GTE nodes for Tegra264
arm64: tegra: Add Host1x and VIC on Tegra264
arm64: tegra: Populate CPU and L2 cache nodes on Tegra264
arm64: tegra: Enable GPCDMA in Tegra264 and add iommu-map
Linux 7.2-rc5
super: fix emergency thaw deadlock on frozen block devices
tracing: perf: Fix stale head for perf syscall tracing
ftrace: Add global mutex to serialize trace_parser access
tracing: Delay module ref count for "enable_event" trigger
tracing: Fix use-after-free freeing trigger private data
bpf, sockmap: Fix cork use-after-free in tcp_bpf_sendmsg()
tracing: Fix context switch counter truncation
...
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fix from Ingo Molnar:
- Fix MCE CMCI discovery initialization ordering bug (Breno Leitao)
* tag 'x86-urgent-2026-08-08' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mce: Set up the polling timer before CMCI discovery
|
|
While OpenRISC currently doesn't fail to build upstream, it appears that
including <asm/smp.h> in the right headers is enough to break that -
primarily because OpenRISC's asm/smp.h header doesn't actually provide
any definition for struct cpumask. Which means the only reason we aren't
failing to build the kernel is because we've been lucky enough that
every spot including asm/smp.h already has definitions for struct
cpumask pulled in.
This became evident when trying to work on a patch series for adding
ref-counted interrupt enable/disable to the kernel, where introducing a
new interrupt_rc.h header suddenly introduced a build error on OpenRISC:
In file included from include/linux/interrupt_rc.h:17,
from include/linux/spinlock.h:60,
from include/linux/mmzone.h:8,
from include/linux/gfp.h:7,
from include/linux/mm.h:7,
from arch/openrisc/include/asm/pgalloc.h:20,
from arch/openrisc/include/asm/io.h:18,
from include/linux/io.h:12,
from drivers/irqchip/irq-ompic.c:61:
arch/openrisc/include/asm/smp.h:21:59: warning: 'struct cpumask'
declared inside parameter list will not be visible outside of this
definition or declaration
21 | extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
| ^~~~~~~
arch/openrisc/include/asm/smp.h:23:54: warning: 'struct cpumask'
declared inside parameter list will not be visible outside of this
definition or declaration
23 | extern void set_smp_cross_call(void (*)(const struct cpumask *, unsigned int));
| ^~~~~~~
drivers/irqchip/irq-ompic.c: In function 'ompic_of_init':
>> drivers/irqchip/irq-ompic.c:191:28: error: passing argument 1 of
'set_smp_cross_call' from incompatible pointer type
[-Werror=incompatible-pointer-types]
191 | set_smp_cross_call(ompic_raise_softirq);
| ^~~~~~~~~~~~~~~~~~~
| |
| void (*)(const struct cpumask *, unsigned int)
arch/openrisc/include/asm/smp.h:23:32: note: expected 'void (*)(const
struct cpumask *, unsigned int)' but argument is of type 'void
(*)(const struct cpumask *, unsigned int)'
23 | extern void set_smp_cross_call(void (*)(const struct cpumask *, unsigned int));
To fix this, let's take an example from the smp.h headers of other
architectures (x86, hexagon, arm64, probably more): just include
linux/cpumask.h at the top.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Boqun Feng <boqun@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Stafford Horne <shorne@gmail.com>
Link: https://patch.msgid.link/20260804161447.84806-5-boqun@kernel.org
|
|
In order to use preempt_count() to track the interrupt disable nesting
level, __preempt_count_{add,sub}_return() are introduced, as their names
suggest, these primitives return the new value of the preempt_count()
after changing it. The following example shows the usage of it in
local_interrupt_disable():
// increase the HARDIRQ_DISABLE bit
new_count = __preempt_count_add_return(HARDIRQ_DISABLE_OFFSET);
// if it's the first-time increment, then disable the interrupt
// at hardware level.
if ((new_count & HARDIRQ_DISABLE_MASK) == HARDIRQ_DISABLE_OFFSET) {
local_irq_save(flags);
raw_cpu_write(local_interrupt_disable_state, flags);
}
Having these primitives will avoid a read of preempt_count() after
changing preempt_count() on certain architectures.
Signed-off-by: Boqun Feng <boqun@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Heiko Carstens <hca@linux.ibm.com> # s390
Link: https://patch.msgid.link/20260804161447.84806-4-boqun@kernel.org
|
|
When running on a setup affected with broken CNTVOFF_EL2
(has_broken_cntvoff())
Booting with VHE or protected mode(nvhe) (id_aa64mmfr1.vh=0
and arm64_sw.hvhe=0) works fine.
However launching a protected VM with protected hvhe mode panics the
guest kernel:
[ 0.000000] Internal error: Oops - Undefined instruction: 0000000000000000 [#1] SMP
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.2.0-rc3-g05f75bd71e0e-dirty #29 PREEMPT
[ 0.000000] Hardware name: linux,dummy-virt (DT)
[ 0.000000] pstate: 000003c5 (nzcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.000000] pc : arch_timer_shutdown_virt+0x4/0x1c
[ 0.000000] lr : arch_timer_starting_cpu+0x1c4/0x2d4
[ 0.000000] sp : ffffa6bd9a193c00
[ 0.000000] x29: ffffa6bd9a193c20 x28: ffffa6bd9a1bcf88 x27: 0000000000000000
[ 0.000000] x26: ffff00001be70dd8 x25: ffffa6bd99d85000 x24: ffffa6bd99d85ee4
[ 0.000000] x23: ffffa6bd99d85000 x22: ffffa6bd9a1499c0 x21: ffffa6bd9a1ab900
[ 0.000000] x20: 00ffffffffffffff x19: ffff00001be8b600 x18: 000000000000028c
[ 0.000000] x17: 00000000510f0010 x16: 00000000510f0010 x15: 00000000500f0000
[ 0.000000] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000018
[ 0.000000] x11: ffffa6bd9a8ac000 x10: 0000000000f0000f x9 : ffffffffffffffff
[ 0.000000] x8 : ffffa6bd98822e18 x7 : 0070752d65746174 x6 : 00111ff76e007261
[ 0.000000] x5 : ffffa6bd9ad68078 x4 : 0000000000000000 x3 : ffffa6bd98822a0c
[ 0.000000] x2 : 0000000000000073 x1 : 0000000000000001 x0 : ffff00001be8b600
[ 0.000000] Call trace:
[ 0.000000] arch_timer_shutdown_virt+0x4/0x1c (P)
[ 0.000000] cpuhp_invoke_callback+0x11c/0x280
[ 0.000000] cpuhp_issue_call+0x1e8/0x224
[ 0.000000] __cpuhp_setup_state_cpuslocked+0x1d8/0x2b8
[ 0.000000] __cpuhp_setup_state+0x50/0x74
[ 0.000000] arch_timer_register+0xc0/0x148
[ 0.000000] arch_timer_of_init+0x148/0x170
[ 0.000000] timer_probe+0x74/0x124
[ 0.000000] time_init+0x18/0x58
[ 0.000000] start_kernel+0x1c0/0x3ac
[ 0.000000] __primary_switched+0x88/0x90
[ 0.000000] Code: c80b7d2a 35ffffab 17ffffeb d503245f (d53be328)
The workaround avoids setting non-zero CNTVOFF_EL2 and trapping the
virtual counter to emulate the offset.
In the VHE path (timer_set_traps()), traps are only enabled when the
guest actually has a non-zero virtual timer offset.
However, __timer_enable_traps() in hyp/nvhe/timer-sr.c unconditionally
set CNTHCTL_EL1TVT and CNTHCTL_EL1TVCT whenever has_broken_cntvoff()
was true.
Which causes 2 issues:
1) Protected VMs: kvm_handle_pvm_sysreg() does not find "cntv_ctl_el0"
in pvm_sys_reg_descs and injects undefined instruction exceptions.
2) non-protected guests are trapped all the time even with offset of
zero.
Fix this by adding a check in __timer_enable_traps() similar to the one in
timer_set_traps()
Fixes: 0bc9a9e85fcf ("KVM: arm64: Work around x1e's CNTVOFF_EL2 bogosity")
Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com>
Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Tested-by: Fuad Tabba <fuad.tabba@linux.dev>
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Link: https://patch.msgid.link/20260808085824.732659-4-smostafa@google.com
Signed-off-by: Oliver Upton <oupton@kernel.org>
|
|
With pKVM, protected VMs always have offset of zero.
However, timer offsets for non-protected guests fail to take effect
for two reasons:
1) In __timer_enable_traps(), enabling of traps check for
is_protected_kvm_enabled() rather than vcpu_is_protected(vcpu)
2) The vcpu timer offsets were never initialised and kept as NULL.
This is problematic for cases when the timer is trapped in the
hypervisor as the with the case of broken CNTVOFF_EL2, which leads
to the hypervisor and host using different offsets and causing VM
hangs.
This can be confirmed by running the arch_timer selftest which fails:
./arch_timer -o 100000000
Random seed: 0x6b8b4567
Guest assert failed, vcpu 0; stage; 3; iter: 0
==== Test Assertion Failure ====
arm64/arch_timer.c:137: config_iter + 1 == irq_iter
pid=310 tid=312 errno=4 - Interrupted system call
Guest assert failed, vcpu 3; stage; 3; iter: 0
Guest assert failed, vcpu 1; stage; 3; iter: 0
==== Test Assertion Failure ====
arm64/arch_timer.c:137: config_iter + 1 == irq_iter
pid=310 tid=313 errno=4 - Interrupted system call
Guest assert failed, vcpu 2; stage; 3; iter: 0
==== Test Assertion Failure ====
arm64/arch_timer.c:137: config_iter + 1 == irq_iter
pid=310 tid=314 errno=4 - Interrupted system call
[...]
After the fix:
./arch_timer -o 100000000
Random seed: 0x6b8b4567
PASS(vCPU-1).
PASS(vCPU-3).
PASS(vCPU-0).
PASS(vCPU-2)
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: cb0c272acebd ("KVM: arm64: Initialize the hypervisor's VM state at EL2")
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Link: https://patch.msgid.link/20260808085824.732659-3-smostafa@google.com
Signed-off-by: Oliver Upton <oupton@kernel.org>
|
|
We currently have two implementations of get_timer offset(), one
in arm_arch_timer.h, and another one in switch.h.
These two only differ by a pair of kern_hyp_va(), which seems a
pretty weak reason to open-code it.
Turn this function into a macro to avoid the include dependency hell
on kern_hyp_va(), and make it work correctly in all contexts.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Link: https://patch.msgid.link/20260808085824.732659-2-smostafa@google.com
Signed-off-by: Oliver Upton <oupton@kernel.org>
|
|
Having established that our VNCR TLB tracking was flawed and having
dropped it from KVM, it is time to replace it with something that
actually works in order to get some performance back, as the TLBI
overhead is otherwise pretty high.
The goal of such tracking is to hit the TLBI slow path if there are
any VNCR TLBs in the guest, irrespective of their mapping state.
For this purpose, we introduce an VM wide counter (vncr_tlb_count)
that tracks how many valid VNCR TLB are present. This means that
creating such TLB must increment the counter, and invalidation
decrement it, and both these operations must be done with the MMU lock
held for write.
On TLBI handling affecting EL2 S1, a non-zero counter forces the
handling to take the slow path to consider the VNCR TLBs. Note that
the bumping up is done "speculatively" in order to make sure that a
concurrent invalidation will be taken on the slow path.
Not exactly rocket science. Hopefully I got it right this time.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://patch.msgid.link/20260806091026.620700-9-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
|
|
A VNCR TLB invalidation can occur on one vcpu while another vcpu is
faulting in this same page. Without correctly handling this, we can
end up with the following scenario:
- vcpu A walks the PTs to translate VNCR
- before vcpu A is able to grab the MMU lock to insert the TLB,
vcpu B updates the S1 PTs with an invalid entry, and issues
a TLBI S1E2 for this VA
- vcpu A inserts the TLB for something that is now invalid
This isn't a new problem, and we manage S2 by having the MMU notifier
to bump up mmu_invalidate_seq on invalidation so that the fault can be
replayed.
We can perform something similar here, and extend invalidate_vncr_va() to
update the same counter, clearly indicating that the context has
changed under our feet. This is safe as the invalidation always happen
while holding the MMU lock for write, and that we sample the sequence
number before walking S1.
Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2")
Reported-by: sashiko-bot@kernel.org
Link: https://lore.kernel.org/r/20260801130454.5D9F11F00AC4@smtp.kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260806091026.620700-8-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
|
|
When the decode_range_tlbi() helper was moved to be used for S1 TLBIs,
the required sign extension was omitted. Add it.
As a result, special care must be taken to not overflow PA bits when
this is used for S2 invalidation.
Fixes: 85bba00425ae0 ("KVM: arm64: nv: Move TLBI range decoding to a helper")
Reported-by: sashiko-bot@kernel.org
Link: https://lore.kernel.org/r/20260801130337.EB2BA1F00AC4@smtp.kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260806091026.620700-7-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
|
|
While VNCR TLB invalidation always occurs under the MMU lock,
vcpu_put() doesn't, while it unmaps the VNCR page.
The problem is that the invalidation evaluates vncr_tlb::cpu to
decide whether an unmapping needs to take place (cpu != -1) before
performing it. On the other hand, this_cpu_reset_vncr_fixmap()
unconditionally unmaps if L1_VNCR_MAPPED is set.
These two obviously can race, with a TOCTOU pattern on the TLBI
path, and a BUG_ON() on the vcpu_put() path. And the two can end-up
calling vncr_fixmap(-1), with extra lethal effects.
Move the reset of vncr_tlb::cpu to -1 to a common function, and make
this update atomic so that only a single thread can reset the field
and perform the corresponding unmap. The vcpu_put() still need to
unconditionally unmap the current VNCR to close another ugly race.
Finally, the assignment of vncr_tlb::cpu is moved to be kept in sync
with the actual mapping, similar to L1_VNCR_MAPPED being set.
Fixes: 7270cc9157f47 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU notifiers")
Reported-by: sashiko-bot@kernel.org
Link: https://lore.kernel.org/r/20260801130237.0FD8F1F00ACA@smtp.kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com>
Link: https://patch.msgid.link/20260806091026.620700-6-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
|
|
Our TLB invalidation by VA code is based on comparing two ranges,
one defined by the TLB, and one defined by the TLBI instruction.
Each range is defined by a start and a size. However, the way the
comparison is done doesn't account for address rollover, as it
compares an address with (base + size). This works nicely until
this expression represent the last page/block in the TTBR1 VA space,
as the result is a big fat 0. And a failed TLB invalidation.
Rewrite the comparison in a way that is immune to the address
rollover (making the end address inclusive instead of exclusive),
and move this into a common helper that is used by both VA and IPA
invalidations, as suggested by Hyunwoo Kim (although the IPA version
didn't suffer from this particular problem, obviously).
Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2")
Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260806091026.620700-5-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
|
|
We record a VNCR TLB even when SCTLR_EL2.M is 0 in order to make
our life easier. But this is not something that the architecture
anticipate.
As a consequence, a hypervisor is free to set VNCR_EL2 to
some PA when SCTLR_EL2.M==0, use it to run a guest which indirectly
accesses the VNCR page, then eventually set SCTLR_EL2.M==1 with
the same VA. Yes, this is odd, but apparently legal.
A common trick in HW is to invalidate the TLBs on SCTLR_ELx.M being
flipped. But doing this is a not a good idea for us (we'd need to
trap SCTLR accesses), and wouldn't scale as we nest deeper.
Instead, use the fact that the S1 MMU being off at the point of
translation is cached in our TLB, and if it doesn't match the current
MMU state, leave the VNCR unmapped.
Fixes: 2a359e072596f ("KVM: arm64: nv: Handle mapping of VNCR_EL2 at EL2")
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260806091026.620700-4-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
|
|
Computing the effects of a TLB invalidation involves looking at
the size of the mapping cached by the TLB. For S1 mappings such as
VNCR, this is deducted from the combination of the base granule size
and the mapping level.
However, this implies that the S1 MMU is *on*. When the MMU is off,
we indicate this with the level being set to a "creative" value of
-127 (S1_MMU_DISABLED).
This ends-up being misinterpreted by pgshift_level_to_ttl() as it
doesn't handle negative levels at all (the level is immediately cast
to a u8 and only the bottom two bits considered), leading to an
invalidation size of 0. Not helpful.
Tidy-up pgshift_level_to_ttl() to handle these negative levels, and
ttl_to_size() to always return SZ_1G when no valid TTL is present.
This allows the removal of open-coded checks for similar situations.
Note that the check for a negative value not explicitely checking for
S1_MMU_DISABLED is deliberate, so that actual negative levels introduced
with LVA2 and D128 can take the same path if we ever support them.
Fixes: 7270cc9157f47 ("KVM: arm64: nv: Handle VNCR_EL2 invalidation from MMU notifiers")
Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
Link: https://lore.kernel.org/r/ameGoxbn2wzBq2kL@v4bel
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260806091026.620700-3-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
|
|
The global VNCR mapping counter is used to decide whether an L1
provided VNCR page is mapped in L0 on any CPU at the point of
dealing with a TLB invalidation. It is incremented when a mapping
is made in the fixmap, and decremented when unmapped.
As it turns out, this tracking has several flaws:
- we are trying to invalidate TLBs, and the mapping is only an
opportunistic consequence of the TLB. Checking this counter to
decide whether a TLB needs to be invalidated may result in missed
invalidations.
- an L1 vcpu invalidating its own TLB (a very likely case) will not
succeed in invalidating the VNCR pseudo TLB because that page is
not mapped in L0 at this stage.
Given that this tracking fails at delivering the minimum guarantees
that are required and is only a performance optimisation, remove it
completely.
Fixes: 4ffa72ad8f37e ("KVM: arm64: nv: Add S1 TLB invalidation primitive for VNCR_EL2")
Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Link: https://patch.msgid.link/20260806091026.620700-2-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
|
|
The ZBB-optimized strnlen loop loads one word ahead before checking the
aligned boundary:
REG_L t1, SZREG(t0) // load next word
addi t0, t0, SZREG // advance
orc.b t1, t1
bgeu t0, t4, 4f // boundary check AFTER load
where t4 = (s + count) & -SZREG. When s is aligned and count is a
multiple of SZREG, t4 equals s + count and the loop loads a full word
starting at exactly s + count. If s + count falls on a page boundary
with the next page unmapped, this faults.
Fix by computing the aligned boundary from the last valid byte
(s + count - 1) instead of s + count. This makes the loop stop at the
word containing the last valid byte rather than potentially loading the
word after it. The count == 0 case is already handled by the beqz
early exit.
Also add a pre-loop guard (bgeu t0, t4) for the case where all valid
bytes fit within the first word. With the adjusted boundary, t4 can
equal t0, and entering the loop with stale register state from the
first-word processing would produce incorrect results.
The final minu clamp ensures the result is still correct when the last
loaded word extends past s + count - 1 within the same aligned word.
Fixes: 5ba15d419fab ("riscv: lib: add strnlen() implementation")
Signed-off-by: Michael Neuling <mikey@neuling.org>
Assisted-by: Claude Opus4.6 High Thinking
Link: https://patch.msgid.link/20260413010738.1622423-1-mikey@neuling.org
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux into soc/dt
aspeed: First batch of ARM devicetree changes for 7.3
No significant changes this time around. Instead, several cleanups
for Meta's San Miguel platform, along with some changes enabling
dt-check-style.
* tag 'aspeed-arm-7.3-devicetree-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux:
ARM: dts: aspeed: Correct indentation
ARM: dts: aspeed: sanmiguel: fix PDB HSC shunt resistor
ARM: dts: aspeed: sanmiguel: Fix PWRGD_RMC_N active-low hog configuration
ARM: dts: aspeed: sanmiguel: Fix FIO IOEXP interrupt pin
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux into soc/dt
nuvoton: First batch of arm64 devicetree changes for 7.3
Similar to the 7.3 ARM PR for Nuvoton we have a couple of arm64 tidy-ups
from Tomer.
* tag 'nuvoton-arm64-7.3-devicetree-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux:
arm64: dts: nuvoton: npcm845: Reorder timer0 and PECI nodes
arm64: dts: nuvoton: npcm845: Drop redundant timer clock-names
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux into soc/dt
nuvoton: First batch of ARM devicetree changes for 7.3
This time around we have a couple of cleanups from Tomer that make way for
improvements in the bindings.
* tag 'nuvoton-arm-7.3-devicetree-0' of https://git.kernel.org/pub/scm/linux/kernel/git/bmc/linux:
arm: dts: nuvoton: npcm7xx: Drop redundant FIU clock-names
arm: dts: nuvoton: npcm7xx: Drop bogus FIU memory reg-names
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into soc/dt
Allwinner device tree changes for 7.3
Some changes for old chips/devices and some for recent ones.
- A10 PMU interrupt number fixed
- A100/A133 gained LRADC
- enabled overlay support for sun8i-h2-plus pi boards
- A523 family gained consumer IR receiver
- H728-based X96QPRO+ gained SPDIF audio output
- PinePhone's mpu6050 mount orientation fixed
- style fixes
New board added:
- Baijie Helper A133
- NetCube Systems OpenNMC (dobermann)
* tag 'sunxi-dt-for-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
arm64: dts: allwinner: Correct white-space style
ARM: dts: allwinner: Correct white-space style
arm64: dts: allwinner: a523: Enable SPDIF on X96QPRO+
arm64: dts: allwinner: a523: Add SPDIF output PH pin mux option
arm64: dts: allwinner: sun50i-a64-pinephone: Fix mpu6050 mount matrix
arm64: dts: allwinner: a523: enable IR on the Avaota A1
arm64: dts: allwinner: a523: enable IR receiver on the X96Q Pro+
arm64: dts: allwinner: a523: add IR receiver nodes
media: dt-bindings: allwinner,sun4i-a10-ir: add A523 compatible
ARM: dts: allwinner: a10: Fix PMU interrupt
ARM: dts: allwinner: enable overlay support for sun8i-h2-plus pi boards
ARM: dts: allwinner: add support for NetCube Systems OpenNMC (dobermann)
riscv: dts: allwinner: d1s-t113: Add uart4 pinctrl required by NetCube Systems OpenNMC
dt-bindings: arm: sunxi: Add NetCube Systems OpenNMC (dobermann)
ARM: dts: allwinner: sun8i-h3: Correct indentation
arm64: dts: allwinner: A133: add support for Baijie Helper A133 board
arm64: dts: allwinner: a100: Add LRADC node
dt-bindings: input: sun4i-lradc-keys: Add A100/A133 compatible
dt-bindings: arm: sunxi: Add Baijie HelperBoard A133 compatible
dt-bindings: vendor-prefixes: Add Shenzhen Baijie Technology Co., Ltd.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap into soc/dt
ARM: dts: OMAP updates for v7.3
- DT support for PRU-ICSS on AM3/4/5
- minor fixes & cleanups
* tag 'omap-for-v7.3/dt-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap:
ARM: dts: ti/omap: embt2ws: use mulit-led for RGB LED
ARM: dts: ti: omap: Correct indentation
ARM: dts: ti: Fix typos in comments
ARM: dts: ti: Add specific compatibles for SCM conf nodes
arm: dts: ti: Add device tree support for PRU-ICSS on AM335x
arm: dts: ti: Add device tree support for PRU-ICSS on AM437x
arm: dts: ti: Add device tree support for PRU-ICSS on AM57xx
ARM: dts: ti: var-som-om44: Add USB Ethernet controller node
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/spacemit/linux into soc/dt
RISC-V SpacemiT DT changes for 7.3
For K3 SoC
- Enable SD card support
- Enable QSPI
- Fix reset delay of ETH PHY
- Fix PHY ID of ETH
- Symbolic PDAM ID
- Add SPI controller support
- Add USB and PHY support
- Add I2S nodes
For K1 SoC
- Symbolic PDAM ID
- Enable cpufreq support
- Fix max CPU core voltage
For boards of K3
- Pico-ITX
- Enable ALDPS on RTL8211F PHY
- Disable 125MHz clock on RTL8211F PHY
- Enable NOR flash
- Add EEPROM support
- CoM260
- Add EEPROM support
For boards of K1
- Milk-V Jupiter
- Enable CPU DVFS
- Banana Pi BPI-CM6
- Add initial support
- OrangePi R2S
- Enable PCIe
* tag 'spacemit-dt-for-7.3-1' of https://git.kernel.org/pub/scm/linux/kernel/git/spacemit/linux: (33 commits)
riscv: dts: spacemit: Add cpu scaling for Milk-V Jupiter
riscv: dts: spacemit: k1-bananapi-cm6: fix maximum CPU core voltage
riscv: dts: spacemit: k1-orangepi-r2s: fix maximum CPU core voltage
riscv: dts: spacemit: k1-musepi-pro: fix maximum CPU core voltage
riscv: dts: spacemit: k1-orangepi-rv2: fix maximum CPU core voltage
riscv: dts: spacemit: k1-milkv-jupiter: fix maximum CPU core voltage
riscv: dts: spacemit: k1-bananapi-f3: fix maximum CPU core voltage
riscv: dts: spacemit: Make dtschema recognize the etherent PHY correctly on K3 com260 board
riscv: dts: spacemit: Make dtschema recognize the etherent PHY correctly on K3 pico-itx board
riscv: dts: spacemit: k3: add i2s0-i2s5 nodes
riscv: dts: spacemit: k3: add USB controller and USB phy support
riscv: dts: spacemit: enable PCIe on OrangePi R2S
riscv: dts: spacemit: k3-com260-ifx: add eeprom on i2c1
riscv: dts: spacemit: k3-com260: add eeprom on i2c2
riscv: dts: spacemit: add SPI controllers for K3
riscv: dts: spacemit: add K3 PDMA request numbers
riscv: dts: spacemit: Fix phy id check for the phy on com260 board
riscv: dts: spacemit: Fix phy id check for the phy on pico-itx board
riscv: dts: spacemit: Add enough deassert time for the PHY on com260 board
riscv: dts: spacemit: Add enough deassert time for the PHY on PICO ITX
...
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt
New boards: Graperain G3568, HINLINK H28K, LCKFB Taishan Pi 3M,
Orange Pi 5 Pro, Vicharak Axon, Vicharak Vaaman2, Youyeetoo YY3588
New peripherals: eDP support on RK3576
And of course a number of board-fixes, style-fixes and some newly
enabled board-components.
* tag 'v7.3-rockchip-dts64-1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: (39 commits)
arm64: dts: rockchip: Fix rk3566-bigtreetech-cb2 touchscreen property
arm64: dts: rockchip: fix label of sys_led for nanopi-r4s
arm64: dts: rockchip: Fix the rk3566-radxa-cm3 Wifi compatible
arm64: dts: rockchip: Fix Gru WLAN sideband interrupt
arm64: dts: rockchip: Add Vicharak Vaaman2 board
dt-bindings: arm: rockchip: Add Vicharak Vaaman2
arm64: dts: rockchip: add Vicharak Axon board
dt-bindings: arm: rockchip: add Vicharak Axon board
arm64: dts: rockchip: Add LCKFB Taishan Pi 3M
dt-bindings: arm: rockchip: Add LCKFB Taishan Pi 3M
arm64: dts: rockchip: Add Orange Pi 5 Pro board support
arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for Pro
arm64: dts: rockchip: rename PLDO regulator labels to match schematic on rk3588s-orangepi-5
dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
arm64: dts: rockchip: Add devicetree for the Graperain G3568 v2
dt-bindings: arm: rockchip: Add Graperain G3568 series
dt-bindings: vendor-prefixes: Add graperain
Revert "arm64: dts: rockchip: Further describe the WiFi for the Pinephone Pro"
arm64: dts: rockchip: fix HDMI-RX signal detect GPIO on yy3588
arm64: dts: rockchip: Enable USB device mode on rk3588s-roc-pc
...
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux into soc/dt
Amlogic ARM64 DT for v7.3:
- Amlogic AXG fixups for PCIe and NAND
- Overall indentation and whitespace fixups
- Amlogic A9 Pinctrl & GPIO IRQ nodes
- Clock measure nodes for Amlogic T7 & A1
* tag 'amlogic-arm64-dt-for-v7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux:
arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for PCIe
arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to nand_all_pins
arm64: dts: amlogic: meson-axg: Disable nfc node by default
arm64: dts: amlogic: Correct indentation and whitespace
arm64: dts: amlogic: add some device nodes for A9
arm64: dts: amlogic: t7: Add clk measure support
arm64: dts: meson: a1: Add clk measure support
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt
Qualcomm Arm64 DeviceTree updates for v7.3
Introduce DeviceTree support for the Shikra SoC, its GCC and RPM clock
controllers, CQM, CQS, and IQS SoM platforms, and their evaluation boards.
Document the Hawi and Maili SoCs.
Add the Eliza CQS SoM and EVK platforms, the QCS8550 RB5 Gen 2, Vicharak
Axon Mini, HONOR MagicBook Art 14, Microsoft Surface Pro 12, Xiaomi 12 Lite,
Motorola Edge 30, Sony Xperia M2, and Motorola Moto G2 device trees.
Extend Eliza support with USB, SD card, touchscreen, PMIC, interconnect,
thermal, CPU and LLCC bandwidth-monitor, QUPv3, and ADSP GPR descriptions.
Expand Glymur support with GPU, camera and EVA clock controllers, LPASS
audio, CoreSight, PCIe, USB, IMEM and PIL memory regions, power domains,
thermal cooling, and CRD peripherals. Add SoCCP, PMIC regulator, TRNG, and
CPU-capacity descriptions.
Add display, IPA, camera, USB, audio, crypto, TRNG, CoreSight, and thermal
support to the Kaanapali, Milos, Hamoa, and related platforms. Add embedded
controller support for Hamoa and Glymur boards.
Improve networking-platform descriptions with IPQ PCIe port, PHY, clock,
PWM, regulator, and interrupt updates. Update CTCU, display, Iris, audio,
camera, PCIe, USB-C, power-domain, memory-region, and thermal descriptions
across established Qualcomm platforms.
Correct bindings and DeviceTree validation for Qualcomm compatible strings,
legacy fallback compatibles, node naming and formatting, address ranges,
clock specifiers, reserved memory, regulators, GPIOs, and peripheral wiring.
* tag 'qcom-arm64-for-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (244 commits)
arm64: dts: qcom: eliza: Describe the ADSP GPR node
arm64: dts: qcom: eliza-evk: Add support for USB and SD card
dt-bindings: arm: qcom-soc: Allow WSA88xx speaker compatible
dt-bindings: arm: qcom-soc: Validate nodes with fallbacks
dt-bindings: arm: qcom-soc: Document more of existing legacy style compatibles
dt-bindings: arm: qcom-soc: Include Eliza, Kaanapali and others in SoC names
arm64: dts: qcom: eliza: Enable cpufreq cooling devices
arm64: dts: qcom: glymur: add SoCCP DT node
arm64: dts: qcom: glymur: fix SoCCP memory mappings
arm64: dts: qcom: mahua: Add QREF regulator supplies to TCSR
arm64: dts: qcom: glymur: Add QREF regulator supplies to TCSR
arm64: dts: qcom: glymur: Add CX power domain to GCC
arm64: dts: qcom: glymur: Drop fake PCIe phy 3B
arm64: dts: qcom: glymur: add TRNG node
arm64: dts: qcom: glymur: enable ETR and CTCU devices
arm64: dts: qcom: glymur: Add PCIe port compatibles and ports
arm64: dts: qcom: smb2370: Disable SMB2370_2 by default
arm64: dts: qcom: eliza-mtp: Enable touchscreen
arm64: dts: qcom: purwa-iot-som: enable video
arm64: dts: qcom: purwa: Override Iris clocks and operating points
...
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into soc/dt
arm64: dts: NXP device tree updates for v7.3
New boards and SOM support:
- Variscite DART-MX8M-MINI, DART-MX8M-PLUS, VAR-SOM-MX8 QuadMax
(with Sonata and Symphony carrier boards)
- TQMa8MPxS (i.MX8MP) with LVDS overlays, TQMa9596LA on MBa95xxCA; TQMa91xx
on MBa93xxCA
- imx8mm-verdin: Toradex DSI displays (7"/10.1"), HDMI adapter, NAU8822 BTL
audio, Cortex-M4F remoteproc and UART overlay
i.MX8:
- PCIe: add power supply properties to Root Port nodes.
- imx8mp-evk add typec and usb3_phy1 tuning; imx8mq-evk add typec;
- imx8mp-evk add flexcan2 overlay and CAN2/MICFIL board mux; imx8mp-frdm
fix HDMI DDC pinctrl
- imx8mp-var-som-symphony: add second Ethernet, CAN, PWM1, ECSPI2,
capacitive touchscreen, HDMI, PCIe, USB, TPM, external RTC, input
keys, header UARTs
- imx8mq-evk: add DCSS node, uart3/bluetooth node
- imx8qm: add SCU power key, lsio mu8/mu8b, spdif1, lpuart4 nodes;
fix LPCG clock indices for ASRC0; add Variscite Symphony board support
- imx8ulp: add I3C2, eDMA channel properties, LPUART6 (BT) and LPUART7,
gpio-keys power button; correct SRAM node address/size; update rpmsg
resource table address; rename 9x9-evk model string
- imx8mp: enable MU2 for DSP communication (imx8mp-ab2)
i.MX9:
- PCIe: add Root Port nodes with correct outbound address space for
imx94/imx943/imx95; add dma/intr/aer/pme interrupts for imx95 PCIe;
remove 'supports-clkreq' from imx943-evk PCIe1
- imx95: switch USB3 controller to flattened model; add CM7/CM33S nodes
for imx943/imx952/imx95-19x19-evk; add imx94 DMA channels (xspi);
enable NETC block control and in-band SFP status (imx95-var-dart);
add wm8904 DMICDAT1; add lpuart5 alias (imx95-toradex-smarc)
- imx93: add LVDS Display Bridge support with DY1212W-4856 panel overlay
for imx93-11x11-evk; add LVDS overlays for imx93-tqma9352 boards;
update TMU compatible string; fix memory node for imx93-kontron
- imx91: add WM8524 and PDM microphone sound cards, CAN overlay, audio
board muxes (imx91-9x9-qsb); move ELE reserved memory into 512MB
range; USB phy adjustments (imx91-tqma9131)
Layerscape / S32G:
- ls1028a/ls1046a/ls1088a/ls208xa/lx2160a/lx2162a: describe Lynx 10G
SerDes blocks; refactor lx2160a PCIe and SerDes into separate dtsi
files; transition to device-specific SerDes compatible strings
- s32g: add GPR syscon region; describe GPIO and EIRQ in SIUL2 pinctrl
Cleanup and warning fixes:
- correct imx8/s32g3 indentation
- imx8mp: add missing #sound-dai-cells to xcvr
* tag 'imx-dt64-7.3' of https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux: (131 commits)
arm64: dts: imx95: Add dma, intr, aer and pme interrupts for PCIe
arm64: dts: imx94-xspi: add the DMA channels
arm64: dts: freescale: imx8mm-verdin: Add Cortex-M4F UART_4 overlay
arm64: dts: freescale: imx8mm-verdin: Add Cortex-M4F remoteproc
arm64: dts: freescale: imx8mm-verdin: Add Toradex Capacitive Touch Display 7" DSI
arm64: dts: freescale: imx8mm-verdin: Add Toradex Capacitive Touch Display 10.1" DSI
arm64: dts: freescale: imx8mm-verdin: Add Toradex DSI to LVDS adapter with 10.1" display
arm64: dts: freescale: imx8mm-verdin: Add DSI to HDMI adapter overlay
arm64: dts: freescale: imx8mm-verdin: Add NAU8822 Bridge Tied Load
arm64: dts: imx95-var-dart-sonata: enable in-band status for SFP
arm64: dts: imx8ulp-evk: Update rpmsg resource table address
arm64: dts: imx943-evk: Add CM7 and CM33S nodes
arm64: dts: imx952-evk: Add CM7 node and related memory nodes
arm64: dts: imx95-19x19-evk: Add CM7 node and related memory nodes
arm64: dts: imx8qm-var-som-symphony: enable expansion header UART
arm64: dts: imx8ulp-9x9-evk: Rename model string to reflect die size
arm64: dts: imx8ulp-evk: Change the values of some PCRs of ENET
arm64: dts: imx8ulp-evk: Enable LPUART7
arm64: dts: imx8ulp-evk: Enable LPUART6 for Bluetooth
arm64: dts: imx8ulp-evk: Add gpio-keys node for power button
...
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
into soc/dt
ARM64: DT: HiSilicon ARM64 DT updates for v7.3
- Correct indentation
- Drop unused clock-names and reset-names to fix warnings
* tag 'hisi-arm64-dt-for-7.3' of https://github.com/hisilicon/linux-hisi:
arm64: dts: hisilicon: Correct indentation
arm64: dts: hisilicon: hi3798cv200: Drop unused clock-names and reset-names
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Madhavan Srinivasan:
- A couple of fixes for a memory leak and a underflow case
Thanks to George Wilson and R Nageswara Sastry
* tag 'powerpc-7.2-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
powerpc/pseries: lparcfg - fix kbuf[] underflow
powerpc/pseries: pci - logic bug
powerpc/pseries: papr-phy-attest - validate cmd.length, plug mem leak
|
|
When a CPU is taken offline or enters deep idle states, hypervisor CSR
state is lost. The kvm_former_vcpu fast-path optimization caches the
last VCPU that ran on each CPU to avoid expensive CSR restoration when
the same VCPU is re-scheduled on the same CPU. However, if this cache
is not cleared when CSR state is lost, the next VCPU entry will
incorrectly skip CSR restoration, leading to corrupt hypervisor state.
Add kvm_riscv_clear_former_vcpu() to invalidate the per-CPU cache and
call it from kvm_arch_disable_virtualization_cpu() to ensure proper CSR
restoration after CPU offline or system suspend events.
Fixes: 1323a5cfe52c ("KVM: riscv: Skip CSR restore if VCPU is reloaded on the same core")
Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com>
Reviewed-by: Nutty Liu <nutty.liu@hotmail.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20260721-kvm-cpu-pm-v4-1-146bf942547d@sifive.com
Signed-off-by: Anup Patel <anup@brainfault.org>
|
|
SBI PMU EVENT_GET_INFO stores guest-controlled num_events * sizeof(*einfo)
in a 32-bit integer. On RV64, num_events = 0x10000001 makes 0x100000010
truncate to 16. KVM then allocates one entry but loops over the original
num_events, causing out-of-bounds reads and writes. A nested guest
triggered:
BUG: KASAN: slab-out-of-bounds in kvm_riscv_vcpu_pmu_event_info+0xa4/0x142
Read of size 4 at addr ff600000074d46b0 by task init/1
Call Trace:
[<ffffffff8006471c>] kvm_riscv_vcpu_pmu_event_info+0xa4/0x142
[<ffffffff800690c0>] kvm_sbi_ext_pmu_handler+0xca/0x268
[<ffffffff8006779e>] kvm_riscv_vcpu_sbi_ecall+0xec/0x1e6
[<ffffffff8006008c>] kvm_riscv_vcpu_exit+0x48c/0x540
[<ffffffff8005ea0a>] kvm_arch_vcpu_ioctl_run+0x37e/0xc80
Allocated by task 1:
__kmalloc_noprof+0x19e/0x4b0
kvm_riscv_vcpu_pmu_event_info+0x72/0x142
kvm_sbi_ext_pmu_handler+0xca/0x268
kvm_riscv_vcpu_sbi_ecall+0xec/0x1e6
kvm_riscv_vcpu_exit+0x48c/0x540
kvm_arch_vcpu_ioctl_run+0x37e/0xc80
The buggy address is located 0 bytes to the right of
allocated 16-byte region [ff600000074d46a0, ff600000074d46b0)
Store the shared-memory size in size_t and reject multiplication overflow.
Allocate the guest-driven array with GFP_KERNEL_ACCOUNT so it is charged
to kmemcg, and use __GFP_NOWARN to suppress allocation failure warnings.
Use kvcalloc() to allow vmalloc fallback and an unsigned long loop index
to match num_events.
Reported-by: Naveed Khan <naveed@digiscrypt.com>
Closes: https://lore.kernel.org/kvm/178345245327.72065.13249716450708539854@digiscrypt.com/
Fixes: e309fd113b9f ("RISC-V: KVM: Implement get event info function")
Cc: stable@vger.kernel.org
Signed-off-by: Guidong Han <2045gemini@gmail.com>
Reviewed-by: Anup Patel <anup@brainfault.org>
Link: https://lore.kernel.org/r/20260730092533.1369531-1-2045gemini@gmail.com
Signed-off-by: Anup Patel <anup@brainfault.org>
|
|
save_args() reads stack-passed arguments relative to rbp assuming two
return addresses sit between the saved rbp and the arguments, which
holds when the trampoline is entered through the fentry call from a
traced function. An indirect trampoline is called through a function
pointer, so only the caller's return address is on the stack and the
arguments start at rbp + 16, not rbp + 24. Every stack-passed argument
of a struct_ops callback with more than six argument slots is read one
slot off.
This has gone unnoticed because no in-tree struct_ops member passes
arguments on the stack. The jmp-entry form already accounts for having
a single return address; treat BPF_TRAMP_F_INDIRECT the same way.
Fixes: 473e3150e30a ("bpf, x86: allow function arguments up to 12 for TRACING")
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Tested-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://patch.msgid.link/20260808003938.3486067-12-memxor@gmail.com
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
|
