The current approach to nested GICv3 support is to not do anything
while L2 is running, wait a transition from L2 to L1 to resync
LRs, VMCR and HCR, and only then evaluate the state to decide
whether to generate a maintenance interrupt.
This doesn't provide a good quality of emulation, and it would be
far preferable to find out early that we need to perform a switch.
Move the LRs/VMCR and HCR resync into vgic_v3_sync_nested(), so
that we have most of the state available. As we turning the vgic
off at this stage to avoid a screaming host MI, add a new helper
vgic_v3_flush_nested() that switches the vgic on again. The MI can
then be directly injected as required.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-35-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
CPUs lacking TDIR always trap ICV_DIR_EL1, no matter what, since
we have ICH_HCR_EL2.TC set permanently. For these CPUs, it is
useless to use a broadcast kick on SPI injection, as the sole
purpose of this is to set TDIR.
We can therefore skip this on these CPUs, which are challenged
enough not to be burdened by extra IPIs. As a consequence,
permanently set the TDIR bit in the shadow state to notify the
fast-path emulation code of the exit reason.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-34-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
Even when we have either an LR overflow or SPIs in flight, it is
extremely likely that the interrupt being deactivated is still in
the LRs, and that going all the way back to the the generic trap
handling code is a waste of time.
Instead, try and deactivate in place when possible, and only if
this fails, perform a full exit.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-33-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
SPIs are specially annpying, as they can be activated on a CPU and
deactivated on another. WHich means that when an SPI is in flight
anywhere, all CPUs need to have their TDIR trap bit set.
This translates into broadcasting an IPI across all CPUs to make sure
they set their trap bit, The number of in-flight SPIs is kept in
an atomic variable so that CPUs can turn the trap bit off as soon
as possible.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-32-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
Deactivation via ICV_DIR_EL1 is both relatively straightforward
(we have the interrupt that needs deactivation) and really awkward.
The main issue is that the interrupt may either be in an LR on
another CPU, or ourside of any LR.
In the former case, we process the deactivation is if ot was
a write to GICD_CACTIVERn, which is already implemented as a big
hammer IPI'ing all vcpus. In the latter case, we just perform
a normal deactivation, similar to what we do for EOImode==0.
Another annoying aspect is that we need to tell the CPU owning
the interrupt that its ap_list needs laudering. We use a brand new
vcpu request to that effect.
Note that this doesn't address deactivation via the GICV MMIO view,
which will be taken care of in a later change.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-29-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
Now that we can identify interrupts that have not made it into the LRs,
it becomes relatively easy to use EOIcount to walk the overflow list.
What is a bit odd is that we compute a fake LR for the original
state of the interrupt, clear the active bit, and feed into the existing
logic for processing. In a way, this is what would have happened if
the interrupt was in an LR.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-28-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
Now that we always reconfigure the vgic HCR register on entry,
the "enable" part of kvm_vgic_vcpu_enable() is pretty useless.
Removing the enable bits from these functions makes it plain that
they are just about computing the reset state. Just rename the
functions accordingly.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-23-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
We currently don't use the maintenance interrupt very much, apart
from EOI on level interrupts, and for LR underflow in limited cases.
However, as we are moving toward a setup where active interrupts
can live outside of the LRs, we need to use the MIs in a more
diverse set of cases.
Add a new helper that produces a digest of the ap_list, and use
that summary to set the various control bits as required.
This slightly changes the way v2 SGIs are handled, as they used to
count for more than one interrupt, but not anymore.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-22-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
We currently save/restore the VMCR register in a pretty lazy way
(on load/put, consistently with what we do with the APRs).
However, we are going to need the group-enable bits that are backed
by VMCR on each entry (so that we can avoid injecting interrupts for
disabled groups).
Move the synchronisation from put to sync, which results in some minor
churn in the nVHE hypercalls to simplify things.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-21-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
Not programming GICH_HCR while no LRs are populated is a bit
of an issue, as we otherwise don't see any maintenance interrupt
when the guest interacts with the LRs.
Decouple the two and always program the control register, even when
we don't have to touch the LRs.
This is very similar to what we are already doing for GICv3.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-17-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
EOIcount is how the virtual CPU interface signals that the guest
is deactivating interrupts outside of the LRs when EOImode==0.
We therefore need to preserve that information so that we can find
out what actually needs deactivating, just like we already do on
GICv3.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-16-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
Not programming ICH_HCR_EL2 while no LRs are populated is a bit
of an issue, as we otherwise don't see any maintenance interrupt
when the guest interacts with the LRs.
Decouple the two and always program the control register, even when
we don't have to touch the LRs.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-13-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
Despite LPIs not having an active state, *virtual* LPIs do have
one, which gets cleared on EOI. So far, so good.
However, this leads to a small problem: when an active LPI is not
in the LRs, that EOImode==0 and that the guest EOIs it, EOIcount
doesn't get bumped up. Which means that in these condition, the
LPI would stay active forever.
Clearly, we can't have that. So if we spot an active LPI, we drop
that state. It's pretty pointless anyway, and only serves as a way
to trip SW over.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-11-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
A long time ago, an unsuspecting architect forgot to add a trap
bit for ICV_DIR_EL1 in ICH_HCR_EL2. Which was unfortunate, but
what's a bit of spec between friends? Thankfully, this was fixed
in a later revision, and ARM "deprecates" the lack of trapping
ability.
Unfortuantely, a few (billion) CPUs went out with that defect,
anything ARMv8.0 from ARM, give or take. And on these CPUs,
you can't trap DIR on its own, full stop.
As the next best thing, we can trap everything in the common group,
which is a tad expensive, but hey ho, that's what you get. You can
otherwise recycle the HW in the neaby bin.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-7-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
As we are about to start trapping a bunch of extra things, augment
the pKVM trap description with all the registers trapped by ICH_HCR_EL2.TC,
making them legal instead of resulting in a UNDEF injection in the guest.
While we're at it, ensure that pKVM captures the vgic model so that it
can be checked by the emulation code.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-6-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
The trap bits are currently only set to manage CPU errata. However,
we are about to make use of them for purposes beyond beating broken
CPUs into submission.
For this purpose, turn these errata-driven bits into a patched-in
constant that is merged with the KVM-driven value at the point of
programming the ICH_HCR_EL2 register, rather than being directly
stored with with the shadow value..
This allows the KVM code to distinguish between a trap being handled
for the purpose of an erratum workaround, or for KVM's own need.
Tested-by: Fuad Tabba <tabba@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://msgid.link/20251120172540.2267180-5-maz@kernel.org
Signed-off-by: Oliver Upton <oupton@kernel.org>
Pull char/misc driver fixes from Greg KH:
"Here are some small char/misc/android driver fixes for 6.18-rc3 for
reported issues. Included in here are:
- rust binder fixes for reported issues
- mei device id addition
- mei driver fixes
- comedi bugfix
- most usb driver bugfixes
- fastrpc memory leak fix
All of these have been in linux-next for a while with no reported
issues"
* tag 'char-misc-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
most: usb: hdm_probe: Fix calling put_device() before device initialization
most: usb: Fix use-after-free in hdm_disconnect
binder: remove "invalid inc weak" check
mei: txe: fix initialization order
comedi: fix divide-by-zero in comedi_buf_munge()
mei: late_bind: Fix -Wincompatible-function-pointer-types-strict
misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookup
mei: me: add wildcat lake P DID
misc: amd-sbi: Clarify that this is a BMC driver
nvmem: rcar-efuse: add missing MODULE_DEVICE_TABLE
binder: Fix missing kernel-doc entries in binder.c
rust_binder: report freeze notification only when fully frozen
rust_binder: don't delete FreezeListener if there are pending duplicates
rust_binder: freeze_notif_done should resend if wrong state
rust_binder: remove warning about orphan mappings
rust_binder: clean `clippy::mem_replace_with_default` warning
Pull staging driver fixes from Greg KH:
"Here are some small staging driver fixes for the gpib subsystem to
resolve some reported issues. Included in here are:
- memory leak fixes
- error code fixes
- proper protocol fixes
All of these have been in linux-next for almost 2 weeks now with no
reported issues"
* tag 'staging-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: gpib: Fix device reference leak in fmh_gpib driver
staging: gpib: Return -EINTR on device clear
staging: gpib: Fix sending clear and trigger events
staging: gpib: Fix no EOI on 1 and 2 byte writes
Pull tty/serial driver fixes from Greg KH:
"Here are some small tty and serial driver fixes for reported issues.
Included in here are:
- sh-sci serial driver fixes
- 8250_dw and _mtk driver fixes
- sc16is7xx driver bugfix
- new 8250_exar device ids added
All of these have been in linux-next this past week with no reported
issues"
* tag 'tty-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
serial: 8250_mtk: Enable baud clock and manage in runtime PM
serial: 8250_dw: handle reset control deassert error
dt-bindings: serial: sh-sci: Fix r8a78000 interrupts
serial: sc16is7xx: remove useless enable of enhanced features
serial: 8250_exar: add support for Advantech 2 port card with Device ID 0x0018
tty: serial: sh-sci: fix RSCI FIFO overrun handling
Pull USB driver fixes from Greg KH:
"Here are some small USB driver fixes and new device ids for 6.18-rc3.
Included in here are:
- new option serial driver device ids added
- dt bindings fixes for numerous platforms
- xhci bugfixes for many reported regressions
- usbio dependency bugfix
- dwc3 driver fix
- raw-gadget bugfix
All of these have been in linux-next this week with no reported issues"
* tag 'usb-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
USB: serial: option: add Telit FN920C04 ECM compositions
USB: serial: option: add Quectel RG255C
tcpm: switch check for role_sw device with fw_node
usb/core/quirks: Add Huawei ME906S to wakeup quirk
usb: raw-gadget: do not limit transfer length
USB: serial: option: add UNISOC UIS7720
xhci: dbc: enable back DbC in resume if it was enabled before suspend
xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event
usb: xhci-pci: Fix USB2-only root hub registration
dt-bindings: usb: qcom,snps-dwc3: Fix bindings for X1E80100
usb: misc: Add x86 dependency for Intel USBIO driver
dt-bindings: usb: switch: split out ports definition
usb: dwc3: Don't call clk_bulk_disable_unprepare() twice
dt-bindings: usb: dwc3-imx8mp: dma-range is required only for imx8mp
Pull x86 fixes from Borislav Petkov:
- Remove dead code leftovers after a recent mitigations cleanup which
fail a Clang build
- Make sure a Retbleed mitigation message is printed only when
necessary
- Correct the last Zen1 microcode revision for which Entrysign sha256
check is needed
- Fix a NULL ptr deref when mounting the resctrl fs on a system which
supports assignable counters but where L3 total and local bandwidth
monitoring has been disabled at boot
* tag 'x86_urgent_for_v6.18_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/bugs: Remove dead code which might prevent from building
x86/bugs: Qualify RETBLEED_INTEL_MSG
x86/microcode: Fix Entrysign revision check for Zen1/Naples
x86,fs/resctrl: Fix NULL pointer dereference with events force-disabled in mbm_event mode
Pull irq fixes from Borislav Petkov:
- Restore the original buslock locking in a couple of places in the irq
core subsystem after a rework
* tag 'irq_urgent_for_v6.18_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
genirq/manage: Add buslock back in to enable_irq()
genirq/manage: Add buslock back in to __disable_irq_nosync()
genirq/chip: Add buslock back in to irq_set_handler()
Pull objtool fixes from Borislav Petkov:
- Fix x32 build due to wrong format specifier on that sub-arch
- Add one more Rust noreturn function to objtool's list
* tag 'objtool_urgent_for_v6.18_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
objtool: Fix failure when being compiled on x32 system
objtool/rust: add one more `noreturn` Rust function
Pull scheduler fix from Borislav Petkov:
- Make sure a CFS runqueue on a throttled hierarchy has its PELT clock
throttled otherwise task movement and manipulation would lead to
dangling cfs_rq references and an eventual crash
* tag 'sched_urgent_for_v6.18_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/fair: Start a cfs_rq on throttled hierarchy with PELT clock throttled
Pull timer fix from Borislav Petkov:
- Do not create more than eight (max supported) AUX clocks sysfs
hierarchies
* tag 'timers_urgent_for_v6.18_rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
timekeeping: Fix aux clocks sysfs initialization loop bound
Pull driver core fixes from Danilo Krummrich:
- In Device::parent(), do not make any assumptions on the device
context of the parent device
- Check visibility before changing ownership of a sysfs attribute
group
- In topology_parse_cpu_capacity(), replace an incorrect usage of
PTR_ERR_OR_ZERO() with IS_ERR_OR_NULL()
- In devcoredump, fix a circular locking dependency between
struct devcd_entry::mutex and kernfs
- Do not warn about a pending fw_devlink sync state
* tag 'driver-core-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core:
arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()
rust: device: fix device context of Device::parent()
sysfs: check visibility before changing group attribute ownership
devcoredump: Fix circular locking dependency with devcd->mutex.
driver core: fw_devlink: Don't warn about sync_state() pending
Pull firewire fixes from Takashi Sakamoto:
"A small collection of FireWire fixes. This includes corrections to
sparse and API documentation"
* tag 'firewire-fixes-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
firewire: init_ohci1394_dma: add missing function parameter documentation
firewire: core: fix __must_hold() annotation
Pull RISC-V fixes from Paul Walmsley:
- Close a race during boot between userspace vDSO usage and some
late-initialized vDSO data
- Improve performance on systems with non-CPU-cache-coherent
DMA-capable peripherals by enabling write combining on
pgprot_dmacoherent() allocations
- Add human-readable detail for RISC-V IPI tracing
- Provide more information to zsmalloc on 64-bit RISC-V to improve
allocation
- Silence useless boot messages about CPUs that have been disabled in
DT
- Resolve some compiler and smatch warnings and remove a redundant
macro
* tag 'riscv-for-linus-6.18-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: hwprobe: avoid uninitialized variable use in hwprobe_arch_id()
riscv: cpufeature: avoid uninitialized variable in has_thead_homogeneous_vlenb()
riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot
riscv: add a forward declaration for cpuinfo_op
RISC-V: Don't print details of CPUs disabled in DT
riscv: Remove the PER_CPU_OFFSET_SHIFT macro
riscv: mm: Define MAX_POSSIBLE_PHYSMEM_BITS for zsmalloc
riscv: Register IPI IRQs with unique names
ACPI: RIMT: Fix unused function warnings when CONFIG_IOMMU_API is disabled
RISC-V: Define pgprot_dmacoherent() for non-coherent devices
Pull xfs fixes from Carlos Maiolino:
"The main highlight here is a fix for a bug brought in by the removal
of attr2 mount option, where some installations might actually have
'attr2' explicitly configured in fstab preventing system to boot by
not being able to remount the rootfs as RW.
Besides that there are a couple fix to the zonefs implementation,
changing XFS_ONLINE_SCRUB_STATS to depend on DEBUG_FS (was select
before), and some other minor changes"
* tag 'xfs-fixes-6.18-rc3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: fix locking in xchk_nlinks_collect_dir
xfs: loudly complain about defunct mount options
xfs: always warn about deprecated mount options
xfs: don't set bt_nr_sectors to a negative number
xfs: don't use __GFP_NOFAIL in xfs_init_fs_context
xfs: cache open zone in inode->i_private
xfs: avoid busy loops in GCD
xfs: XFS_ONLINE_SCRUB_STATS should depend on DEBUG_FS
xfs: do not tightly pack-write large files
xfs: Improve CONFIG_XFS_RT Kconfig help
Pull smb server fixes from Steve French:
"smbdirect (RDMA) fixes in order avoid potential submission queue
overflows:
- free transport teardown fix
- credit related fixes (five server related, one client related)"
* tag 'v6.18-rc2-smb-server-fixes' of git://git.samba.org/ksmbd:
smb: server: let free_transport() wait for SMBDIRECT_SOCKET_DISCONNECTED
smb: client: make use of smbdirect_socket.send_io.lcredits.*
smb: server: make use of smbdirect_socket.send_io.lcredits.*
smb: server: simplify sibling_list handling in smb_direct_flush_send_list/send_done
smb: server: smb_direct_disconnect_rdma_connection() already wakes all waiters on error
smb: smbdirect: introduce smbdirect_socket.send_io.lcredits.*
smb: server: allocate enough space for RW WRs and ib_drain_qp()
Clang is not happy with set but unused variable (this is visible
with `make W=1` build:
kernel/sched/sched.h:3744:18: error: variable 'cpumask' set but not used [-Werror,-Wunused-but-set-variable]
It seems like the variable was never used along with the assignment
that does not have side effects as far as I can see. Remove those
altogether.
Fixes: 223baf9d17 ("sched: Fix performance regression introduced by mm_cid")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Eric Biggers <ebiggers@kernel.org>
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Marc Zyngier
Linus Torvalds
Andy Shevchenko