.../virt/kvm/devices/arm-vgic-v3.rst | 24 ++++++-- arch/arm64/include/uapi/asm/kvm.h | 7 +++ arch/arm64/kvm/vgic/vgic-init.c | 3 + arch/arm64/kvm/vgic/vgic-its.c | 2 +- arch/arm64/kvm/vgic/vgic-kvm-device.c | 39 +++++++++++++ arch/arm64/kvm/vgic/vgic-mmio-v3.c | 12 ++-- arch/arm64/kvm/vgic/vgic-v3.c | 16 ++++- arch/arm64/kvm/vgic/vgic-v4.c | 8 +-- include/kvm/arm_vgic.h | 5 ++ tools/testing/selftests/kvm/arm64/vgic_init.c | 58 +++++++++++++++++++ 10 files changed, 157 insertions(+), 17 deletions(-)
Hello,
When kvm-arm.vgic_v4_enable=1, KVM adds support for direct interrupt
injection by default to all the VMs in the system, aka GICv4. A
shortcoming of the GIC architecture is that there's an absolute limit on
the number of vPEs that can be tracked by the ITS. It is possible that
an operator is running a mix of VMs on a system, only wanting to provide
a specific class of VMs with hardware interrupt injection support.
To support this, introduce a GIC attribute, KVM_DEV_ARM_VGIC_CONFIG_GICV4,
for the userspace to enable or disable vGICv4 for a given VM.
The attribute allows the configuration only when vGICv4 is enabled in KVM,
else it acts a read-only attribute returning
KVM_DEV_ARM_VGIC_CONFIG_GICV4_UNAVAILABLE as the value.
On the other hand, if KVM has the vGICv4 enabled via the cmdline, the
VM absorbs this configuration by default to maintain the backward
compatibility. Userspace can get the attribute's value to check if the VM
has vGICv4 support if it sees KVM_DEV_ARM_VGIC_CONFIG_GICV4_ENABLE as the
value. As required, it can disable vGICv4 by setting
KVM_DEV_ARM_VGIC_CONFIG_GICV4_DISABLE as the value.
The patches are distrubuted as:
Patch-1 contains the KVM code that introduces the
KVM_DEV_ARM_VGIC_CONFIG_GICV4 attr, and adds all the support around it.
Patch-2 adds the documentation for the said attribute.
Patch-3 extends the vgic_init kvm/arm64 selftest that tests the get and
set of this attribute in various configurations.
Thank you.
Raghavendra
Raghavendra Rao Ananta (3):
kvm: arm64: Add support for KVM_DEV_ARM_VGIC_CONFIG_GICV4 attr
docs: kvm: devices/arm-vgic-v3: Document KVM_DEV_ARM_VGIC_CONFIG_GICV4
attr
KVM: selftests: Extend vgic_init to test GICv4 config attr
.../virt/kvm/devices/arm-vgic-v3.rst | 24 ++++++--
arch/arm64/include/uapi/asm/kvm.h | 7 +++
arch/arm64/kvm/vgic/vgic-init.c | 3 +
arch/arm64/kvm/vgic/vgic-its.c | 2 +-
arch/arm64/kvm/vgic/vgic-kvm-device.c | 39 +++++++++++++
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 12 ++--
arch/arm64/kvm/vgic/vgic-v3.c | 16 ++++-
arch/arm64/kvm/vgic/vgic-v4.c | 8 +--
include/kvm/arm_vgic.h | 5 ++
tools/testing/selftests/kvm/arm64/vgic_init.c | 58 +++++++++++++++++++
10 files changed, 157 insertions(+), 17 deletions(-)
base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8
--
2.49.0.1101.gccaa498523-goog
Hi, On 5/14/25 20:21, Raghavendra Rao Ananta wrote: > Hello, > > When kvm-arm.vgic_v4_enable=1, KVM adds support for direct interrupt > injection by default to all the VMs in the system, aka GICv4. A > shortcoming of the GIC architecture is that there's an absolute limit on > the number of vPEs that can be tracked by the ITS. It is possible that > an operator is running a mix of VMs on a system, only wanting to provide > a specific class of VMs with hardware interrupt injection support. > > To support this, introduce a GIC attribute, KVM_DEV_ARM_VGIC_CONFIG_GICV4, > for the userspace to enable or disable vGICv4 for a given VM. > > The attribute allows the configuration only when vGICv4 is enabled in KVM, > else it acts a read-only attribute returning > KVM_DEV_ARM_VGIC_CONFIG_GICV4_UNAVAILABLE as the value. What's the reason for the cmdline enable continuing to be absolute in the disable case? I wonder if this is unnecessarily restrictive. Couldn't KVM_DEV_ARM_VGIC_CONFIG_GICV4_UNAVAILABLE be reserved for hardware that doesn't support vgic_v4 and if kvm-arm.vgic_v4_enable=0, or omitted, on supporting hardware then default to KVM_DEV_ARM_VGIC_CONFIG_GICV4_DISABLE but allow it to be overridden? I don't think this changes the behaviour when your new attribute is not used. > > On the other hand, if KVM has the vGICv4 enabled via the cmdline, the > VM absorbs this configuration by default to maintain the backward > compatibility. Userspace can get the attribute's value to check if the VM > has vGICv4 support if it sees KVM_DEV_ARM_VGIC_CONFIG_GICV4_ENABLE as the > value. As required, it can disable vGICv4 by setting > KVM_DEV_ARM_VGIC_CONFIG_GICV4_DISABLE as the value. > ... > > Thanks, Ben
On Thu, May 15, 2025 at 3:30 AM Ben Horgan <ben.horgan@arm.com> wrote: > > Hi, > > On 5/14/25 20:21, Raghavendra Rao Ananta wrote: > > Hello, > > > > When kvm-arm.vgic_v4_enable=1, KVM adds support for direct interrupt > > injection by default to all the VMs in the system, aka GICv4. A > > shortcoming of the GIC architecture is that there's an absolute limit on > > the number of vPEs that can be tracked by the ITS. It is possible that > > an operator is running a mix of VMs on a system, only wanting to provide > > a specific class of VMs with hardware interrupt injection support. > > > > To support this, introduce a GIC attribute, KVM_DEV_ARM_VGIC_CONFIG_GICV4, > > for the userspace to enable or disable vGICv4 for a given VM. > > > > The attribute allows the configuration only when vGICv4 is enabled in KVM, > > else it acts a read-only attribute returning > > KVM_DEV_ARM_VGIC_CONFIG_GICV4_UNAVAILABLE as the value. > What's the reason for the cmdline enable continuing to be absolute in > the disable case? I wonder if this is unnecessarily restrictive. > > Couldn't KVM_DEV_ARM_VGIC_CONFIG_GICV4_UNAVAILABLE be reserved for > hardware that doesn't support vgic_v4 and if kvm-arm.vgic_v4_enable=0, > or omitted, on supporting hardware then default to > KVM_DEV_ARM_VGIC_CONFIG_GICV4_DISABLE but allow it to be overridden? I > don't think this changes the behaviour when your new attribute is not used. KVM_DEV_ARM_VGIC_CONFIG_GICV4_UNAVAILABLE is reserved for the exact situation that you mentioned (no GICv4 h/w support or if cmdline is disabled/omitted). Regarding defaulting to KVM_DEV_ARM_VGIC_CONFIG_GICV4_DISABLE, wouldn't it change the existing expectations, i.e., vGICv4 is enabled if available and set by cmdline? Thank you. Raghavendra
Hi, On 5/15/25 16:55, Raghavendra Rao Ananta wrote: > On Thu, May 15, 2025 at 3:30 AM Ben Horgan <ben.horgan@arm.com> wrote: >> >> Hi, >> >> On 5/14/25 20:21, Raghavendra Rao Ananta wrote: >>> Hello, >>> >>> When kvm-arm.vgic_v4_enable=1, KVM adds support for direct interrupt >>> injection by default to all the VMs in the system, aka GICv4. A >>> shortcoming of the GIC architecture is that there's an absolute limit on >>> the number of vPEs that can be tracked by the ITS. It is possible that >>> an operator is running a mix of VMs on a system, only wanting to provide >>> a specific class of VMs with hardware interrupt injection support. >>> >>> To support this, introduce a GIC attribute, KVM_DEV_ARM_VGIC_CONFIG_GICV4, >>> for the userspace to enable or disable vGICv4 for a given VM. >>> >>> The attribute allows the configuration only when vGICv4 is enabled in KVM, >>> else it acts a read-only attribute returning >>> KVM_DEV_ARM_VGIC_CONFIG_GICV4_UNAVAILABLE as the value. >> What's the reason for the cmdline enable continuing to be absolute in >> the disable case? I wonder if this is unnecessarily restrictive. >> >> Couldn't KVM_DEV_ARM_VGIC_CONFIG_GICV4_UNAVAILABLE be reserved for >> hardware that doesn't support vgic_v4 and if kvm-arm.vgic_v4_enable=0, >> or omitted, on supporting hardware then default to >> KVM_DEV_ARM_VGIC_CONFIG_GICV4_DISABLE but allow it to be overridden? I >> don't think this changes the behaviour when your new attribute is not used. > > KVM_DEV_ARM_VGIC_CONFIG_GICV4_UNAVAILABLE is reserved for the exact > situation that you mentioned (no GICv4 h/w support or if cmdline is > disabled/omitted). > Regarding defaulting to KVM_DEV_ARM_VGIC_CONFIG_GICV4_DISABLE, > wouldn't it change the existing expectations, i.e., vGICv4 is enabled > if available and set by cmdline? I was suggesting keeping the defaults the same when your new gic attribute is untouched but in the same way that it overrides enable to disable you could also allow it to override disable to enable. Based on Marc's comments this does not seem desirable. As things are now, and with your changes, setting kvm-arm.vgic_v4_enable=1 at boot implies a promise that vgic_v4 works on the system. As there is broken hardware we can't take this promise for granted. > > Thank you. > Raghavendra Thanks, Ben
On Thu, 15 May 2025 11:30:33 +0100, Ben Horgan <ben.horgan@arm.com> wrote: > > Hi, > > On 5/14/25 20:21, Raghavendra Rao Ananta wrote: > > Hello, > > > > When kvm-arm.vgic_v4_enable=1, KVM adds support for direct interrupt > > injection by default to all the VMs in the system, aka GICv4. A > > shortcoming of the GIC architecture is that there's an absolute limit on > > the number of vPEs that can be tracked by the ITS. It is possible that > > an operator is running a mix of VMs on a system, only wanting to provide > > a specific class of VMs with hardware interrupt injection support. > > > > To support this, introduce a GIC attribute, KVM_DEV_ARM_VGIC_CONFIG_GICV4, > > for the userspace to enable or disable vGICv4 for a given VM. > > > > The attribute allows the configuration only when vGICv4 is enabled in KVM, > > else it acts a read-only attribute returning > > KVM_DEV_ARM_VGIC_CONFIG_GICV4_UNAVAILABLE as the value. > What's the reason for the cmdline enable continuing to be absolute in > the disable case? I wonder if this is unnecessarily restrictive. Because there are a number of GICv4 implementations that are absolutely terrible out there, and that will happily lock-up under some undisclosed circumstances. So unless you find a good way to retire that HW, GICv4 will continue to be a buy-in. M. -- Without deviation from the norm, progress is not possible.
© 2016 - 2026 Red Hat, Inc.