summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-07-31i3c: renesas: Use reset_control_bulk_{assert, deassert}()Claudiu Beznea
Use reset_control_bulk_assert() and reset_control_bulk_deassert() in the suspend and resume paths to simplify the code. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-10-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Fix out-of-bounds access for newdevs maskClaudiu Beznea
When software initiates DAA (Dynamic Address Assignment), the controller reports the result via the NRSPQP (Normal Response Queue Port Register). The data length field of the response descriptor, which is accessible through the NRSPQP register, indicates the number of devices remaining after DAA. Consequently, when the bus is empty, this field contains the maximum number of devices supported by the controller (8 for the Renesas I3C controller). Adjust the condition that computes the newly discovered devices bitmask to prevent an out-of-bounds when the I3C bus is empty. Fixes: e7218986319b ("i3c: renesas: Add suspend/resume support") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-9-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Clean DATBAS register on detachClaudiu Beznea
The controller uses DATBAS registers on TX/RX logic. Clean the DATBAS register for the detached I3C device to avoid issues. Fixes: d028219a9f14 ("i3c: master: Add basic driver for the Renesas I3C controller") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-8-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Perform Dynamic Address Assignment on resumeClaudiu Beznea
The Renesas RZ/G3S SoC supports a power saving mode where power to most SoC components, including I3C, is turned off. On systems where the I3C devices also loses power during suspend (e.g. NXP P3T1085UK-ARD connected to the PMOD1_6A connector of the RZ SMARC Carrier 2 + Renesas RZ/G3S SMARC SOM), the devices becomes unreachable after resume. Running DAA in the controller resume path restores communication. However, DAA relies on interrupts for TX/RX, which are not available in the noirq suspend/resume phase (unless they are wakeup interrupts). For this, the suspend/resume callbacks were moved out of the noirq phase. Currently, there is no identified use case on either the Renesas RZ/G3S or Renesas RZ/G3E SoCs that requires the controller suspend/resume hooks to be part of the noirq suspend/resume phase. Since renesas_i3c_reset() is not called anymore in atomic context update it to use read_poll_timeout(). Along with this, struct renesas_i3c::DATBASn and its usage were removed, as they are no longer needed. Fixes: e7218986319b ("i3c: renesas: Add suspend/resume support") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-7-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Reset the controller on resumeClaudiu Beznea
Reset the controller on resume after enabling the clocks to follow the same sequence as in probe and avoid potential ordering related failures. With it, renesas_i3c_reset() was updated to use read_poll_timeout_atomic(), as the driver's resume callback is executed during the noirq phase of resume, where interrupts are disabled. Fixes: e7218986319b ("i3c: renesas: Add suspend/resume support") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-6-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Reconfigure the DATBAS register on re-attachClaudiu Beznea
During re-attach, the device may change its position in the i3c->addrs[] array. As a result, it may use a different Device Address Table Basic Register (DATBAS), which needs to be reconfigured. Reconfigure the DATBAS register on re-attach. Along with it update software caches. Fixes: d028219a9f14 ("i3c: master: Add basic driver for the Renesas I3C controller") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-5-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Follow the reset deassert order used in probeClaudiu Beznea
Use the same reset deassert order in the resume and probe paths to avoid potential failures due to ordering differences. Fixes: e7218986319b ("i3c: renesas: Add suspend/resume support") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-4-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Restore STDBR and EXTBR registers on resumeClaudiu Beznea
The Renesas RZ/G3S supports a power saving state where power to the most SoC componentes (including I3C) is lost. The STDBR and EXTBR are configured in initialization phase though the struct i3c_master_controller_ops::bus_init. Set them on resume function as well to keep the same state of the controller after a suspend with power loss and a similar initialization sequence as in bus_init. Fixes: e7218986319b ("i3c: renesas: Add suspend/resume support") Cc: stable@vger.kernel.org Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-3-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: renesas: Check that the transfer is valid before accessing itClaudiu Beznea
The Renesas I3C driver uses an asynchronous model to transfer data. It prepares a struct renesas_i3c_xfer, enqueues it, and waits for completion. The interrupt handler dequeues the transfer, updates/uses it, and signals the waiting thread. If the completion times out, the waiting thread dequeues the transfer and free it. If an interrupt fires after that, the handler may access freed memory, leading to crashes. Check that the transfer is still valid before accessing it in the interrupt handler. With it clear any status flags and disable all the interrupts to avoid triggering the same interrupts again. Fixes: d028219a9f14 ("i3c: master: Add basic driver for the Renesas I3C controller") Cc: stable@vger.kernel.org Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Link: https://patch.msgid.link/20260713130545.568657-2-claudiu.beznea+renesas@tuxon.dev Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Add driver for AMD AXI I3C master controllerManikanta Guntupalli
Add an I3C master driver and maintainers fragment for the AMD I3C bus controller. The driver currently supports the I3C bus operating in SDR mode, with features including Dynamic Address Assignment, private data transfers, and CCC transfers in both broadcast and direct modes. It also supports operation in I2C mode. The controller's data FIFOs are accessed big-endian; the driver performs this conversion locally using ioread32be()/iowrite32be() with the helpers, so it does not depend on any core FIFO-endianness helpers. Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli@amd.com> Co-developed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com> Co-developed-by: Shubham Patil <shubhamsanjay.patil@amd.com> Signed-off-by: Shubham Patil <shubhamsanjay.patil@amd.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260709064233.1451482-3-shubhamsanjay.patil@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31dt-bindings: i3c: Add AMD I3C master controller supportManikanta Guntupalli
Add device tree binding documentation for the AMD I3C master controller version 1.0. Signed-off-by: Manikanta Guntupalli <manikanta.guntupalli@amd.com> Co-developed-by: Shubham Patil <shubhamsanjay.patil@amd.com> Signed-off-by: Shubham Patil <shubhamsanjay.patil@amd.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com> Link: https://patch.msgid.link/20260709064233.1451482-2-shubhamsanjay.patil@amd.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Add optional_bytes for variable-length GET CCC validationAdrian Ng Ho Yin
Add optional_bytes to struct i3c_ccc_cmd_payload so callers describe variable-length GET CCC responses. GETMRL and GETMXDS set optional_bytes at the call site. Extend i3c_ccc_validate_payload_len() to honour it. Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> # on RZ/G3S Link: https://patch.msgid.link/2e07dc944eab1c4358be1da87fa5000e711ac8bd.1783493868.git.tze.yee.ng@altera.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Validate GET CCC payload length and retry Direct GET onceAdrian Ng Ho Yin
Add retries to struct i3c_ccc_cmd. Validate GET payload length in i3c_master_send_ccc_cmd_locked() after a successful transfer. Retry failed Direct GET CCCs up to cmd->retries times when the driver reports failure or an I3C error; validation failures are not retried. SET CCCs are not retried by default. Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> # on RZ/G3S Link: https://patch.msgid.link/b467f01edfaaa0710f30e719ce7f2753b06c1a3f.1783493868.git.tze.yee.ng@altera.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: dw: Map CCC hardware errors to I3C M0/M2Adrian Ng Ho Yin
Map DesignWare I3C master CCC hardware errors to I3C M0/M2 error codes. I3C_ERROR_M2 is reported only for broadcast address-header NACK (RESPONSE_ERROR_IBA_NACK). Target address NACK remains -EIO. Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> # on RZ/G3S Link: https://patch.msgid.link/05994f0479041f3d8d199babe2a4535d6dcba3bf.1783493868.git.tze.yee.ng@altera.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Report actual GET CCC payload length on successAdrian Ng Ho Yin
Set dests[].payload.actual_len on successful GET CCC transfers in I3C master drivers so the core can distinguish requested and received buffer lengths. Switch core GET helpers to use actual_len instead of len when interpreting GET CCC results. Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> # on RZ/G3S Link: https://patch.msgid.link/6c66571ae7166aa4b87616d900e6d643631ac355.1783493868.git.tze.yee.ng@altera.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: ccc: Add actual_len to struct i3c_ccc_cmd_payloadAdrian Ng Ho Yin
Add actual_len to struct i3c_ccc_cmd_payload so drivers can report how many bytes were received on a GET CCC without overwriting the requested buffer length in len. Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com> Signed-off-by: Tze Yee Ng <tze.yee.ng@altera.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> # on RZ/G3S Link: https://patch.msgid.link/e452777c3a9be734a97e20b9822d8a4264ceadba.1783493868.git.tze.yee.ng@altera.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: Fix device_register() error pathAdrian Hunter
When device_register() fails in i3c_master_register_new_i3c_devs(), put_device() is called to drop the reference taken by device_register(). That drops the last reference, so the device's release callback i3c_device_release() runs and frees the i3c_device. Two problems follow from that: i3c_device_release() does WARN_ON(i3cdev->desc), so it warns because desc->dev->desc still points back at the descriptor. Clear it before calling put_device(). After put_device() frees the i3c_device, desc->dev is left pointing at freed memory, so clear desc->dev as well. That prevents, for example, i3c_master_unregister_i3c_devs() seeing desc->dev as non-NULL and dereferencing it. Reported-by: sashiko-bot@kernel.org Link: https://lore.kernel.org/linux-i3c/20260701203053.8F3971F000E9@smtp.kernel.org/ Fixes: cab63f6488761 ("i3c: Fix potential refcount leak in i3c_master_register_new_i3c_devs") Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260702183644.60827-1-adrian.hunter@intel.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: dw: avoid shift-out-of-bounds when DAA assigns no devicesJakub Kicinski
On an empty bus ENTDAA assigns nothing, so cmd->rx_len (the count of addresses left unassigned) equals master->maxdevs. The GENMASK() index master->maxdevs - cmd->rx_len - 1 then becomes -1, which trips up UBSAN. This happens every time on boot on a Gigabyte/AMD server: UBSAN: shift-out-of-bounds in drivers/i3c/master/dw-i3c-master.c:905:12 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 7 UID: 0 PID: 963 Comm: (udev-worker) Not tainted 7.0.11-200.fc44.x86_64 #1 PREEMPT(lazy) Hardware name: Giga Computing E163-Z34-AAH1-000/MZ33-DC1-000, BIOS R32_F45 04/01/2026 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ubsan_epilogue+0x5/0x2b __ubsan_handle_shift_out_of_bounds.cold+0xd7/0x1ab dw_i3c_master_daa.cold+0x1b/0x96 [dw_i3c_master] i3c_master_do_daa_ext.part.0+0x3e/0xf0 [i3c] Skip the mask when no new device was assigned. Fixes: 1dd728f5d4d4 ("i3c: master: Add driver for Synopsys DesignWare IP") Signed-off-by: Jakub Kicinski <kuba@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260630172904.2662160-1-kuba@kernel.org Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: svc: bound IBI payload to the requested max_payload_lenMaoyi Xie
svc_i3c_master_handle_ibi() reads the IBI payload from the RX FIFO into the IBI slot. The loop is bounded by the hardware FIFO size (SVC_I3C_FIFO_SIZE), not by the slot size. slot->data points into the IBI pool, which i3c_generic_ibi_alloc_pool() sizes at max_payload_len per slot. svc_i3c_master_request_ibi() only rejects a max_payload_len larger than SVC_I3C_FIFO_SIZE, so a driver can request a smaller one. mctp-i3c requests 1. Each readsb() then copies the controller RXCOUNT bytes (up to 31) with no check against the slot size. A device that sends more bytes than the slot holds writes past slot->data, an out-of-bounds write into the IBI pool. Bound the loop by dev->ibi->max_payload_len and clamp each read to the space left in the slot, the same way dw-i3c does. A device can still send more than the requested payload. Flush the leftover bytes from the RX FIFO so they do not leak into the next transfer. Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver") Cc: stable@vger.kernel.org Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg> Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg> Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/178227747353.2931373.15868718612134648277@maoyixie.com Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: svc: report timeout waiting for STOP idlePengpeng Hou
svc_i3c_master_xfer() emits STOP or force-exit for the final transfer and then waits for the controller state to become idle, but ignores readl_poll_timeout(). The function can therefore return success while the controller is still not idle. Return the idle-wait error through the existing warning/FIFO cleanup path so the caller observes the failed transfer without emitting a second STOP after the final STOP or force-exit has already been sent. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://patch.msgid.link/20260623060821.23238-1-pengpeng@iscas.ac.cn Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31i3c: master: adi: initialize the lock before enabling interruptsRunyu Xiao
adi_i3c_master_probe() requests the IRQ and unmasks REG_IRQ_PENDING_CMDR before the controller's IBI state, transfer queue list and transfer queue lock are initialized. A pending CMDR interrupt can therefore run adi_i3c_master_irq() and take master->xferqueue.lock before the dynamic lock has been initialized. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the probe ordering and the IRQ path adi_i3c_master_probe() -> adi_i3c_master_irq() -> xferqueue.lock, with a pending CMDR interrupt arriving after REG_IRQ_PENDING_CMDR is unmasked. Lockdep reported: INFO: trying to register non-static key. you didn't initialize this object before use? lock_acquire+0xbb/0x290 _raw_spin_lock_irqsave+0x36/0x60 adi_i3c_master_irq+0x32/0x56 [vuln_msv] adi_i3c_master_probe+0x5a/0xf47 [vuln_msv] Initialize the transfer queue and IBI state before requesting and unmasking the IRQ. Fixes: a79ac2cdc91d ("i3c: master: Add driver for Analog Devices I3C Controller IP") Cc: stable@vger.kernel.org Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20260617150138.628578-1-runyu.xiao@seu.edu.cn Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2026-07-31arm64: Add override for ID_AA64MMFR4_EL1.NV_fracMarc Zyngier
In a very unsurprising turn of events, there is a large class of firmware that is totally unable to deal with FEAT_NV3, and doesn't set the required SCR2_EL3.NV3En bit, leading to an UNDEF exception or an unhandled trap to EL3, depending on the implementation. Allow the unfortunate user to override ID_AA64MMFR4_EL1.NV_frac and get a working system. Hopefully firmware will be fixed before actually HW ships, but I have been there before... :-/ Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-30-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: selftest: Add NVHCR_EL2 to get-reg-listMarc Zyngier
Since we now expose a new system register on NV3-capable HW when the guest is exposed to it, add it to the existing checker. FWIW. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-29-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Expose FEAT_NV3 to guestsMarc Zyngier
Further enable FEAT_NV3 by making it visible to NV guests. Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-28-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Add FEAT_NV3 detectionMarc Zyngier
Now that everything is in place to engage the FEAT_NV3 fast-path, add the detection code to cpufeature.c. Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-27-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Engage NV3 TLBI trap elisionMarc Zyngier
Similarly to the ERET elision mechanism, FEAT_NV3 can elide TLBIs that only affects the guest's S1 translation. Enable this, with the express condition that the guest isn't NV2 aware, as we otherwise need to trap these TLBIs to deal with VNCR mappings. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-26-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Engage NV3 ERET trap elisionMarc Zyngier
When running on NV3 HW, always engage ERET trap elision when running the L1 context, as there is no benefit in not doing so. An L1 can itself engage trap elision by setting its own view of HCRX_EL2.NVTGE==1, which will subsequently be honored. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-25-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Add NVHCR_EL2 context switchingMarc Zyngier
Since NVHCR_EL2 represents the HCR_EL2 state of the EL1 guest, it must be dealt with in some particular way: - for a guest in hyp context (an L1 by definition), NVHCR_EL2 directly reflects HCR_EL2 as read and written by the guest itself. It must therefore be eagerly synced back with the emulation code which only knows about HCR_EL2. This is unconditional if NV3 is available on the host. - For an L2 guest, NVHCR_EL2 is controlled by the L1 guest, and we just context switch it like any other EL1 register. Yes, EL1, as that's where this thing runs from the PoV of L1. This is conditioned on the guest using NV3. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-24-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Add routing for NVHCR_EL2 trapMarc Zyngier
NVHCR_EL2 accesses from EL1 are taken to EL2 when HCRX_EL2.NVTGE==0 and HCR_EL2.NV==1. Describe this in the exception routing tables. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-23-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Add NVHCR_EL2 handling to the sysreg arrayMarc Zyngier
Expose NVHCR_EL2 to userspace, and treat the direct access as UNDEF, as that would only outline a bug in our exception routing. The generic accessors are also updated to deal with the relatively uncommon location of that register. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-22-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Add sanitisation for NVHCR_EL2Marc Zyngier
Just like any other VNCR-based register, NVHCR_EL2 requires some level of sanitisation. Being specified as a live copy of HCR_EL2, it adopts the exact same format, but depends on FEAT_NV3 instead. A subtle aspect is that we only want to apply the sanitisation if FEAT_NV3 is actually present, as the VNCR location is otherwise used to back accesses to HCR_EL2. Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-21-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Make HCR_EL2 a non-VNCR registerMarc Zyngier
FEAT_NV3 makes a fundamental change to the architecture, by moving guest-initiated HCR_EL2 accesses to the NVHCR_EL2 register. As the names suggests, this is HCR_EL2 for a NV guest. But where do NVHCR_EL2 accesses from a guest go? The are redirected to the VNCR page, right where HCR_EL2 is stored in the NV2 case. Does it hurt? Good. There's more coming. The challenge here is to make KVM work seamlessly, without rewriting everything. Which implies that things such as __vcpu_sys_reg(HCR_EL2) must work, no matter the underlying NV implementation. A simple way to deal with it is to move HCR_EL2's canonical storage outside of VNCR for the vast majority of the KVM code, and only have a copy at entry/exit times. Given that we don't really support NV3 yet, this is pretty simple. In the process, advertise NVHCR_EL2 as the register that now holds offset 0x78 in the VNCR page. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-20-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Add kvm_has_nv{2,3}() predicatesMarc Zyngier
Add a new set of predicates indicating whether VM is capable of NV2, NV3, and is in a nested NV3 context. This is going to become useful as we start dealing with a mix of behaviours (NV2, NV3, NV2 on NV3...). Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-19-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Add NV3 control bits to HCRX_EL2 sanitisationMarc Zyngier
Expose the FEAT_NV3 control bits to the sanitisation code so that KVM stops moaning about the unattributed bits. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Joey Gouly <joey.gouly@arm.com> Link: https://patch.msgid.link/20260730071022.296811-18-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Split NV-specific exit fixups from the non-NV handlingMarc Zyngier
In order to facilitate further changes, move the NV handling of early fixups in its own helper. This also makes the code slightly simpler to parse. Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-17-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31arm64: Add ARM64_HAS_NV3 capabilityMarc Zyngier
As a bunch of KVM code is going to depend on FEAT_NV3 being detected on the host, add a new capability that will describe it. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-16-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31arm64: sysreg: Add HCRX_EL2 bits related to FEAT_NV3Marc Zyngier
FEAT_NV3 introduces 4 new HCRX_EL2 control bits. Describe them in the sysreg file. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Joey Gouly <joey.gouly@arm.com> Link: https://patch.msgid.link/20260730071022.296811-15-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31arm64: sysreg: Add NVHCR_EL2 description as a mirror of HCR_EL2Marc Zyngier
FEAT_NV3 introduces a new register that contains the HCR_EL2 value exposed to a NV guest. As such, it has the exact same layout as HCR_EL2. Describe NVHCR_EL2 as a mapping to HCR_EL2. Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-14-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31arm64: Add FEAT_NV2p1 detectionMarc Zyngier
Add the necessary NV2p1 probing to the cpufeature infrastructure. Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-13-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Expose FEAT_NV2p1 to NV guestsMarc Zyngier
Since NV2p1 is reducing the number of traps, it is valuable to expose it to NV guests. Do so. Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-12-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Relax CNTHCTL_EL2 handling when FEAT_NV2p1 is presentMarc Zyngier
With NV2p1, it is no longer necessary to use the split approach where bits of CNTHCTL_EL2 cannot be accessed via CNTKCTL_EL1, and we can treat the CNTKCTL_EL1 accessor as if it was "normal". Key the special casing on FEAT_NV2P1 not being implemented. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-11-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Relax CPTR_EL2 handling when FEAT_NV2p1 is presentMarc Zyngier
With FEAT_NV2P1, it is no longer necessary to trap CPTR_EL2 accesses via CPACR_EL1, as CPACR_EL1.TCPAC is guaranteed to be stateful. Prevent such trapping and context switch CPACTR_EL1 in NV contexts when NV2P1 is present. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-10-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31arm64: Add ARM64_HAS_NV2P1 capabilityMarc Zyngier
As we're about to deal with FEAT_NV2P1, add a new capability that will be used to key any support for it. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-9-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Don't evaluate HCR_EL2.NV nor HFGITR_EL2.ERET on ERET fast pathMarc Zyngier
We currently avoid using the ERET fast path if the guest has HCR_EL2.NV set. This is an odd check, as NV doesn't mean much if HCR_EL2.TGE==1. Similarly, evaluating HFGITR_EL2.ERET makes little sense, as this only applies to the nested context, while the ERET fast-path is purely for the benefit of L1. Replace these bizarre checks with is_nested_ctxt() which makes a lot more sense: if we are running an L2, the ERET trap must go to L1. Fixes: dd0717a998f77 ("KVM: arm64: nv: Fast-track 'InHost' exception returns") Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-8-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Classify CPTR_EL2 as a SR_LOC_SPECIAL registerMarc Zyngier
It may not be obvious unless you look at it closely, but CPTR_EL2 is treated very differently from other registers. It is one the registers that, despite looking very similar between EL1 and EL2 when E2H==1, have RES0 bits that get in the way. Make it clear that CPTR_EL2 is odd by classifying it as SR_LOC_SPECIAL, just like CNTHCTL_EL2 (and for the same reasons). This makes it possible to use vcpu_read_sys_reg() with it, and will be necessary once we support FEAT_NV2P1. Reviewed-by: Joey Gouly <joey.gouly@arm.com> Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-7-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Plumb HCRX_EL2.SRMASKEn in HCRX_EL2 sanitisationMarc Zyngier
HCRX_EL2.SRMASKEn is a new bit enabling FEAT_SRMASK for a guest. We don't plan to support it any time soon, but it doesn't hurt to actively document it, specially as we are going to add more bits we actually care about. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-6-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Drop __HCRX_EL2_* masksMarc Zyngier
The __HCRX_EL2_* masks are a leftover from a time where we didn't have much sanitisation for the system registers. Since we are now in a better place, rely on the existing checks to detect unhandled bits in HCRX_EL2. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://patch.msgid.link/20260730071022.296811-5-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31KVM: arm64: Merge guest's HCRX_EL2 using NV_HCRX_GUEST_EXCLUDEMarc Zyngier
The way we merge the guest-provided HCRX_EL2 value with the host's is bonkers. We try to make it look like the FGT registers by using positive and negative polarities for traps, but most of these bits are not strictly about trapping, as they actively change the way some architectural state is managed. It would be far better to deal with these bits like we do for HCR_EL2, by enumerating the list of bits we don't allow the guest to override. This is simplified by the fact that HCRX_EL2 only affects EL1, and not EL2. Re-jig the HCRX_EL2 handling with a macro that list the bits excluded from the merge (TMEA, PTTWI, EnIDCP128). Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Joey Gouly <joey.gouly@arm.com> Link: https://patch.msgid.link/20260730071022.296811-4-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31arm64: Update ID_AA64MMFR4_EL1 description to 2026-03 JSON releaseMarc Zyngier
ID_AA64MMFR4_EL1 has gained a few fields and enum values in the past few months, so resync its definition with the 2026-03 JSON release. Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Joey Gouly <joey.gouly@arm.com> Link: https://patch.msgid.link/20260730071022.296811-3-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
2026-07-31arm64: sysreg: Emit RESx/UNKN values for Mapping/Fields definitionsMarc Zyngier
The sysreg file is using the Mapping or Fields qualifiers to indicate that a given encoding is only a mapping to a particular register (or an instance of a more generic register definition). As a result, we don't output any definition, and instead expect the canonical definitions to be used. This works rather well for individual fields, but creates problems for macros that refer to more generic classes of bits such as RESx. Relax the above rule by emitting the RESx and UNKN values for Mapping and Fields qualifiers as well. Signed-off-by: Marc Zyngier <maz@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://patch.msgid.link/20260730071022.296811-2-maz@kernel.org Signed-off-by: Oliver Upton <oupton@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-09-24 02:20:17 +0000