diff options
| author | Sascha Bischoff <Sascha.Bischoff@arm.com> | 2026-09-04 11:39:52 +0000 |
|---|---|---|
| committer | Marc Zyngier <maz@kernel.org> | 2026-09-14 10:49:07 +0100 |
| commit | 884d518cef62c5f4beb940709bf1920021b773b8 (patch) | |
| tree | e381e3e208ca3523ac9f10cce983b382e4c7c79c /tools/perf/scripts/python | |
| parent | 77f7a9282fee67180134e75b107ff09d7e1a5876 (diff) | |
KVM: arm64: gic-v5: Implement VMT/vIST IRS MMIO Ops
GICv5 has rules about which fields of a VMTE (or L1 VMT) may be
directly written by the host once the table is valid. This ensures
that no stale state is cached by the hardware, and provides a clear
interface for making VMs, ISTs, etc. valid.
The hypervisor is responsible for populating the VMTE for a VM.
However, it is not permitted to write the Valid bit, as the VM table
is already valid. Instead, the VM is made valid via an IRS MMIO
operation. The same applies to the ISTs: they must be made valid via
the host IRS.
This commit adds support for:
* Making level 1 VMTs valid, allowing for dynamic level 2 array
allocation
* Making VMTEs, and hence VMs, valid or invalid
* Making SPI ISTs valid, and LPI ISTs valid or invalid, for a specific
VM
As part of this commit, the following vcpu_affinity-based commands are
plumbed in:
VMT_L2_MAP - Make a second level VM table valid
VMTE_MAKE_VALID - Make a single VMTE, and hence VM, valid
VMTE_MAKE_INVALID - Make a single VMTE, and hence VM, invalid
SPI_VIST_MAKE_VALID - Make the SPI IST valid
LPI_VIST_MAKE_VALID - Make the LPI IST valid
LPI_VIST_MAKE_INVALID - Make the LPI IST invalid
The lack of SPI_VIST_MAKE_INVALID is intentional.
An IRS command timeout does not indicate whether the command was
consumed. If VIST assignment times out, retain both the VMTE and IST
allocation and mark the VM dead. This prevents KVM from freeing memory
which may still be accessible to hardware.
When successfully probing for a GICv5, allocate the VMT and make it
valid through the IRS MMIO interface. Treat failures while allocating
or assigning the VMT as hard GICv5 probe failures. At that point the
IRS VM table state is a prerequisite for vGICv5 operation, and falling
back to the legacy path would leave the host without a valid GICv5 VM
table setup.
Conversely, if vGICv5 registration succeeds but registration of the
optional legacy vGICv3 device fails, retain the working vGICv5 device
rather than failing the entire probe.
Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
Link: https://patch.msgid.link/20260904113404.4051341-12-sascha.bischoff@arm.com
Signed-off-by: Marc Zyngier <maz@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
