<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/arch/arm64/include/asm/kvm_host.h, branch linux-7.0.y</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=linux-7.0.y</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=linux-7.0.y'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-05-14T13:31:07+00:00</updated>
<entry>
<title>KVM: arm64: Fix kvm_vcpu_initialized() macro parameter</title>
<updated>2026-05-14T13:31:07+00:00</updated>
<author>
<name>Fuad Tabba</name>
<email>tabba@google.com</email>
</author>
<published>2026-04-24T08:49:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9ecef14983d4574fee03413039654458cd7ff25c'/>
<id>urn:sha1:9ecef14983d4574fee03413039654458cd7ff25c</id>
<content type='text'>
commit d89fdda7dd8a488f922e1175e6782f781ba8a23b upstream.

The macro is defined with parameter 'v' but the body references the
literal token 'vcpu' instead, causing it to silently operate on whatever
'vcpu' resolves to in the caller's scope rather than the value passed by
the caller. All current call sites happen to use a variable named 'vcpu',
so the bug is latent.

Fixes: e016333745c7 ("KVM: arm64: Only reset vCPU-scoped feature ID regs once")
Signed-off-by: Fuad Tabba &lt;tabba@google.com&gt;
Link: https://patch.msgid.link/20260424084908.370776-5-tabba@google.com
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: vgic: Pick EOIcount deactivations from AP-list tail</title>
<updated>2026-03-07T21:45:58+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2026-03-07T19:11:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6da5e537f5afe091658e846da1949d7e557d2ade'/>
<id>urn:sha1:6da5e537f5afe091658e846da1949d7e557d2ade</id>
<content type='text'>
Valentine reports that their guests fail to boot correctly, losing
interrupts, and indicates that the wrong interrupt gets deactivated.

What happens here is that if the maintenance interrupt is slow enough
to kick us out of the guest, extra interrupts can be activated from
the LRs. We then exit and proceed to handle EOIcount deactivations,
picking active interrupts from the AP list. But we start from the
top of the list, potentially deactivating interrupts that were in
the LRs, while EOIcount only denotes deactivation of interrupts that
are not present in an LR.

Solve this by tracking the last interrupt that made it in the LRs,
and start the EOIcount deactivation walk *after* that interrupt.
Since this only makes sense while the vcpu is loaded, stash this
in the per-CPU host state.

Huge thanks to Valentine for doing all the detective work and
providing an initial patch.

Fixes: 3cfd59f81e0f3 ("KVM: arm64: GICv3: Handle LR overflow when EOImode==0")
Fixes: 281c6c06e2a7b ("KVM: arm64: GICv2: Handle LR overflow when EOImode==0")
Reported-by: Valentine Burley &lt;valentine.burley@collabora.com&gt;
Tested-by: Valentine Burley &lt;valentine.burley@collabora.com&gt;
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Link: https://lore.kernel.org/r/20260307115955.369455-1-valentine.burley@collabora.com
Link: https://patch.msgid.link/20260307191151.3781182-1-maz@kernel.org
Cc: stable@vger.kernel.org
</content>
</entry>
<entry>
<title>KVM: arm64: Optimise away S1POE handling when not supported by host</title>
<updated>2026-02-13T14:54:48+00:00</updated>
<author>
<name>Fuad Tabba</name>
<email>tabba@google.com</email>
</author>
<published>2026-02-13T14:38:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9cb0468d0b335ccf769bd8e161cc96195e82d8b1'/>
<id>urn:sha1:9cb0468d0b335ccf769bd8e161cc96195e82d8b1</id>
<content type='text'>
Although ID register sanitisation prevents guests from seeing the
feature, adding this check to the helper allows the compiler to entirely
eliminate S1POE-specific code paths (such as context switching POR_EL1)
when the host kernel is compiled without support (CONFIG_ARM64_POE is
disabled).

This aligns with the pattern used for other optional features like SVE
(kvm_has_sve()) and FPMR (kvm_has_fpmr()), ensuring no POE logic if the
host lacks support, regardless of the guest configuration state.

Signed-off-by: Fuad Tabba &lt;tabba@google.com&gt;
Link: https://patch.msgid.link/20260213143815.1732675-3-tabba@google.com
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge branch kvm-arm64/misc-6.20 into kvmarm-master/next</title>
<updated>2026-02-05T09:17:58+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2026-02-05T09:17:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6316366129d2885fae07c2774f4b7ae0a45fb55d'/>
<id>urn:sha1:6316366129d2885fae07c2774f4b7ae0a45fb55d</id>
<content type='text'>
* kvm-arm64/misc-6.20:
  : .
  : Misc KVM/arm64 changes for 6.20
  :
  : - Trivial FPSIMD cleanups
  :
  : - Calculate hyp VA size only once, avoiding potential mapping issues when
  :   VA bits is smaller than expected
  :
  : - Silence sparse warning for the HYP stack base
  :
  : - Fix error checking when handling FFA_VERSION
  :
  : - Add missing trap configuration for DBGWCR15_EL1
  :
  : - Don't try to deal with nested S2 when NV isn't enabled for a guest
  :
  : - Various spelling fixes
  : .
  KVM: arm64: nv: Avoid NV stage-2 code when NV is not supported
  KVM: arm64: Fix various comments
  KVM: arm64: nv: Add trap config for DBGWCR&lt;15&gt;_EL1
  KVM: arm64: Fix error checking for FFA_VERSION
  KVM: arm64: Fix missing &lt;asm/stackpage/nvhe.h&gt; include
  KVM: arm64: Calculate hyp VA size only once
  KVM: arm64: Remove ISB after writing FPEXC32_EL2
  KVM: arm64: Shuffle KVM_HOST_DATA_FLAG_* indices
  KVM: arm64: Fix comment in fpsimd_lazy_switch_to_host()

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge branch kvm-arm64/resx into kvmarm-master/next</title>
<updated>2026-02-05T09:17:48+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2026-02-05T09:17:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1df3f01ebfb9e7d00fd10711fe9e98b25e01e59a'/>
<id>urn:sha1:1df3f01ebfb9e7d00fd10711fe9e98b25e01e59a</id>
<content type='text'>
* kvm-arm64/resx:
  : .
  : Add infrastructure to deal with the full gamut of RESx bits
  : for NV. As a result, it is now possible to have the expected
  : semantics for some bits such as SCTLR_EL2.SPAN.
  : .
  KVM: arm64: Add debugfs file dumping computed RESx values
  KVM: arm64: Add sanitisation to SCTLR_EL2
  KVM: arm64: Remove all traces of HCR_EL2.MIOCNCE
  KVM: arm64: Remove all traces of FEAT_TME
  KVM: arm64: Simplify handling of full register invalid constraint
  KVM: arm64: Get rid of FIXED_VALUE altogether
  KVM: arm64: Simplify handling of HCR_EL2.E2H RESx
  KVM: arm64: Move RESx into individual register descriptors
  KVM: arm64: Add RES1_WHEN_E2Hx constraints as configuration flags
  KVM: arm64: Add REQUIRES_E2H1 constraint as configuration flags
  KVM: arm64: Simplify FIXED_VALUE handling
  KVM: arm64: Convert HCR_EL2.RW to AS_RES1
  KVM: arm64: Correctly handle SCTLR_EL1 RES1 bits for unsupported features
  KVM: arm64: Allow RES1 bits to be inferred from configuration
  KVM: arm64: Inherit RESx bits from FGT register descriptors
  KVM: arm64: Extend unified RESx handling to runtime sanitisation
  KVM: arm64: Introduce data structure tracking both RES0 and RES1 bits
  KVM: arm64: Introduce standalone FGU computing primitive
  KVM: arm64: Remove duplicate configuration for SCTLR_EL1.{EE,E0E}
  arm64: Convert SCTLR_EL2 to sysreg infrastructure

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge branch kvm-arm64/debugfs-fixes into kvmarm-master/next</title>
<updated>2026-02-05T09:17:44+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2026-02-05T09:17:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3ef5ba663a33aa3da901117acd3555ca582341f0'/>
<id>urn:sha1:3ef5ba663a33aa3da901117acd3555ca582341f0</id>
<content type='text'>
* kvm-arm64/debugfs-fixes:
  : .
  : Cleanup of the debugfs iterator, which are way more complicated
  : than they ought to be, courtesy of Fuad Tabba. From the cover letter:
  :
  : "This series refactors the debugfs implementations for `idregs` and
  :  `vgic-state` to use standard `seq_file` iterator patterns.
  :
  :  The existing implementations relied on storing iterator state within
  :  global VM structures (`kvm_arch` and `vgic_dist`). This approach
  :  prevented concurrent reads of the debugfs files (returning -EBUSY) and
  :  created improper dependencies between transient file operations and
  :  long-lived VM state."
  : .
  KVM: arm64: Use standard seq_file iterator for vgic-debug debugfs
  KVM: arm64: Reimplement vgic-debug XArray iteration
  KVM: arm64: Use standard seq_file iterator for idregs debugfs

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: Add sanitisation to SCTLR_EL2</title>
<updated>2026-02-05T09:02:13+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2026-02-02T18:43:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e8ef27900c6a8c0727dcf62d4112d08c5046d33e'/>
<id>urn:sha1:e8ef27900c6a8c0727dcf62d4112d08c5046d33e</id>
<content type='text'>
Sanitise SCTLR_EL2 the usual way. The most important aspect of
this is that we benefit from SCTLR_EL2.SPAN being RES1 when
HCR_EL2.E2H==0.

Reviewed-by: Fuad Tabba &lt;tabba@google.com&gt;
Tested-by: Fuad Tabba &lt;tabba@google.com&gt;
Link: https://patch.msgid.link/20260202184329.2724080-20-maz@kernel.org
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: Extend unified RESx handling to runtime sanitisation</title>
<updated>2026-02-05T08:59:28+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2026-02-02T18:43:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f9d58956423844237e18a758dc0f1b2cf6480042'/>
<id>urn:sha1:f9d58956423844237e18a758dc0f1b2cf6480042</id>
<content type='text'>
Add a new helper to retrieve the RESx values for a given system
register, and use it for the runtime sanitisation.

This results in slightly better code generation for a fairly hot
path in the hypervisor, and additionally covers all sanitised
registers in all conditions, not just the VNCR-based ones.

Reviewed-by: Fuad Tabba &lt;tabba@google.com&gt;
Tested-by: Fuad Tabba &lt;tabba@google.com&gt;
Link: https://patch.msgid.link/20260202184329.2724080-6-maz@kernel.org
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: Introduce data structure tracking both RES0 and RES1 bits</title>
<updated>2026-02-05T08:59:28+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2026-02-02T18:43:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0879478913dd671b0aed1e3960c4b35fb8546ab4'/>
<id>urn:sha1:0879478913dd671b0aed1e3960c4b35fb8546ab4</id>
<content type='text'>
We have so far mostly tracked RES0 bits, but only made a few attempts
at being just as strict for RES1 bits (probably because they are both
rarer and harder to handle).

Start scratching the surface by introducing a data structure tracking
RES0 and RES1 bits at the same time.

Note that contrary to the usual idiom, this structure is mostly passed
around by value -- the ABI handles it nicely, and the resulting code is
much nicer.

Reviewed-by: Fuad Tabba &lt;tabba@google.com&gt;
Tested-by: Fuad Tabba &lt;tabba@google.com&gt;
Link: https://patch.msgid.link/20260202184329.2724080-5-maz@kernel.org
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
<entry>
<title>KVM: arm64: Use standard seq_file iterator for idregs debugfs</title>
<updated>2026-02-02T10:59:25+00:00</updated>
<author>
<name>Fuad Tabba</name>
<email>tabba@google.com</email>
</author>
<published>2026-02-02T08:57:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dcd79ed450934421158d81600f1be4c2e2af20bf'/>
<id>urn:sha1:dcd79ed450934421158d81600f1be4c2e2af20bf</id>
<content type='text'>
The current implementation uses `idreg_debugfs_iter` in `struct
kvm_arch` to track the sequence position. This effectively makes the
iterator shared across all open file descriptors for the VM.

This approach has significant drawbacks:
- It enforces mutual exclusion, preventing concurrent reads of the
  debugfs file (returning -EBUSY).
- It relies on storing transient iterator state in the long-lived VM
  structure (`kvm_arch`).
- The use of `u8` for the iterator index imposes an implicit limit of
  255 registers. While not currently exceeded, this is fragile against
  future architectural growth. Switching to `loff_t` eliminates this
  overflow risk.

Refactor the implementation to use the standard `seq_file` iterator.
Instead of storing state in `kvm_arch`, rely on the `pos` argument
passed to the `start` and `next` callbacks, which tracks the logical
index specific to the file descriptor.

This change enables concurrent access and eliminates the
`idreg_debugfs_iter` field from `struct kvm_arch`.

Signed-off-by: Fuad Tabba &lt;tabba@google.com&gt;
Link: https://patch.msgid.link/20260202085721.3954942-2-tabba@google.com
Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
</content>
</entry>
</feed>
