KVM unconditionally advertises GICD_TYPER2.nASSGIcap (which internally
implies vSGIs) on GICv4.1 systems. Allow userspace to change whether a
VM supports the feature. Only allow changes prior to VGIC initialization
as at that point vPEs need to be allocated for the VM.
For convenience, bundle support for vLPIs and vSGIs behind this feature,
allowing userspace to control vPE allocation for VMs in environments
that may be constrained on vPE IDs.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
---
.../virt/kvm/devices/arm-vgic-v3.rst | 29 +++++++++++++++
arch/arm64/include/uapi/asm/kvm.h | 3 ++
arch/arm64/kvm/vgic/vgic-init.c | 3 ++
arch/arm64/kvm/vgic/vgic-kvm-device.c | 37 +++++++++++++++++++
arch/arm64/kvm/vgic/vgic-mmio-v3.c | 10 ++++-
arch/arm64/kvm/vgic/vgic-v3.c | 5 ++-
arch/arm64/kvm/vgic/vgic-v4.c | 2 +-
include/kvm/arm_vgic.h | 3 ++
8 files changed, 88 insertions(+), 4 deletions(-)
diff --git a/Documentation/virt/kvm/devices/arm-vgic-v3.rst b/Documentation/virt/kvm/devices/arm-vgic-v3.rst
index e860498b1e35..049d77eae591 100644
--- a/Documentation/virt/kvm/devices/arm-vgic-v3.rst
+++ b/Documentation/virt/kvm/devices/arm-vgic-v3.rst
@@ -306,3 +306,32 @@ Groups:
The vINTID specifies which interrupt is generated when the vGIC
must generate a maintenance interrupt. This must be a PPI.
+
+ KVM_DEV_ARM_VGIC_GRP_FEATURES
+ Attributes:
+
+ KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap
+ Control whether support for SGIs without an active state is exposed
+ to the VM. attr->addr points to a __u8 value which indicates whether
+ he feature is enabled / disabled.
+
+ A value of 0 indicates that the feature is disabled. A nonzero value
+ indicates that the feature is enabled.
+
+ This attribute can only be set prior to initializing the VGIC (i.e.
+ KVM_DEV_ARM_VGIC_CTRL_INIT).
+
+ Support for SGIs without an active state depends on hardware support.
+ Userspace can discover support for the feature by reading the
+ attribute after creating a VGICv3. It is possible that
+ KVM_DEV_ARM_VGIC_CTRL_INIT can later fail if this feature is enabled
+ and KVM is unable to allocate GIC vPEs for the VM.
+
+ Errors:
+
+ ======= ========================================================
+ -ENXIO Invalid attribute in attr->attr
+ -EFAULT Invalid user address in attr->addr
+ -EBUSY The VGIC has already been initialized
+ -EINVAL KVM doesn't support the requested feature setting
+ ======= ========================================================
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index ed5f3892674c..41e9ce412afd 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -417,6 +417,7 @@ enum {
#define KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO 7
#define KVM_DEV_ARM_VGIC_GRP_ITS_REGS 8
#define KVM_DEV_ARM_VGIC_GRP_MAINT_IRQ 9
+#define KVM_DEV_ARM_VGIC_GRP_FEATURES 10
#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT 10
#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK \
(0x3fffffULL << KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT)
@@ -429,6 +430,8 @@ enum {
#define KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES 3
#define KVM_DEV_ARM_ITS_CTRL_RESET 4
+#define KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap 0
+
/* Device Control API on vcpu fd */
#define KVM_ARM_VCPU_PMU_V3_CTRL 0
#define KVM_ARM_VCPU_PMU_V3_IRQ 0
diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
index 5e0e4559004b..944e24750ac4 100644
--- a/arch/arm64/kvm/vgic/vgic-init.c
+++ b/arch/arm64/kvm/vgic/vgic-init.c
@@ -157,6 +157,9 @@ int kvm_vgic_create(struct kvm *kvm, u32 type)
kvm->arch.vgic.in_kernel = true;
kvm->arch.vgic.vgic_model = type;
+ if (type == KVM_DEV_TYPE_ARM_VGIC_V3)
+ kvm->arch.vgic.nassgicap = kvm_vgic_global_state.has_gicv4_1 &&
+ gic_cpuif_has_vsgi();
kvm->arch.vgic.vgic_dist_base = VGIC_ADDR_UNDEF;
diff --git a/arch/arm64/kvm/vgic/vgic-kvm-device.c b/arch/arm64/kvm/vgic/vgic-kvm-device.c
index e28cf68a49c3..629f56063a13 100644
--- a/arch/arm64/kvm/vgic/vgic-kvm-device.c
+++ b/arch/arm64/kvm/vgic/vgic-kvm-device.c
@@ -626,6 +626,26 @@ static int vgic_v3_set_attr(struct kvm_device *dev,
dev->kvm->arch.vgic.mi_intid = val;
return 0;
}
+ case KVM_DEV_ARM_VGIC_GRP_FEATURES: {
+ u8 __user *uaddr = (u8 __user *)attr->addr;
+ u8 val;
+
+ if (attr->attr != KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap)
+ return -ENXIO;
+
+ if (get_user(val, uaddr))
+ return -EFAULT;
+
+ guard(mutex)(&dev->kvm->arch.config_lock);
+ if (vgic_initialized(dev->kvm))
+ return -EBUSY;
+
+ if (!(kvm_vgic_global_state.has_gicv4_1 && gic_cpuif_has_vsgi()) && val)
+ return -EINVAL;
+
+ dev->kvm->arch.vgic.nassgicap = val;
+ return 0;
+ }
default:
return vgic_set_common_attr(dev, attr);
}
@@ -646,6 +666,17 @@ static int vgic_v3_get_attr(struct kvm_device *dev,
guard(mutex)(&dev->kvm->arch.config_lock);
return put_user(dev->kvm->arch.vgic.mi_intid, uaddr);
}
+ case KVM_DEV_ARM_VGIC_GRP_FEATURES: {
+ u8 __user *uaddr = (u8 __user *)attr->addr;
+ u8 val;
+
+ if (attr->attr != KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap)
+ return -ENXIO;
+
+ guard(mutex)(&dev->kvm->arch.config_lock);
+ val = dev->kvm->arch.vgic.nassgicap;
+ return put_user(val, uaddr);
+ }
default:
return vgic_get_common_attr(dev, attr);
}
@@ -683,8 +714,14 @@ static int vgic_v3_has_attr(struct kvm_device *dev,
return 0;
case KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES:
return 0;
+ default:
+ return -ENXIO;
}
+ case KVM_DEV_ARM_VGIC_GRP_FEATURES:
+ return attr->attr != KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap ?
+ -ENXIO : 0;
}
+
return -ENXIO;
}
diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
index 1a9c5b4418b2..43f59e70e1a2 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
@@ -50,12 +50,20 @@ bool vgic_has_its(struct kvm *kvm)
bool vgic_supports_direct_msis(struct kvm *kvm)
{
+ /*
+ * Deliberately conflate vLPI and vSGI support on GICv4.1 hardware,
+ * indirectly allowing userspace to control whether or not vPEs are
+ * allocated for the VM.
+ */
+ if (kvm_vgic_global_state.has_gicv4_1 && !vgic_supports_direct_sgis(kvm))
+ return false;
+
return kvm_vgic_global_state.has_gicv4 && vgic_has_its(kvm);
}
bool vgic_supports_direct_sgis(struct kvm *kvm)
{
- return kvm_vgic_global_state.has_gicv4_1 && gic_cpuif_has_vsgi();
+ return kvm->arch.vgic.nassgicap;
}
/*
diff --git a/arch/arm64/kvm/vgic/vgic-v3.c b/arch/arm64/kvm/vgic/vgic-v3.c
index b9ad7c42c5b0..cb6bda9b3c6c 100644
--- a/arch/arm64/kvm/vgic/vgic-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-v3.c
@@ -404,7 +404,8 @@ int vgic_v3_save_pending_tables(struct kvm *kvm)
* The above vgic initialized check also ensures that the allocation
* and enabling of the doorbells have already been done.
*/
- if (kvm_vgic_global_state.has_gicv4_1) {
+ if (kvm_vgic_global_state.has_gicv4_1 &&
+ vgic_supports_direct_irqs(kvm)) {
unmap_all_vpes(kvm);
vlpi_avail = true;
}
@@ -581,7 +582,7 @@ int vgic_v3_map_resources(struct kvm *kvm)
return -EBUSY;
}
- if (kvm_vgic_global_state.has_gicv4_1)
+ if (vgic_supports_direct_sgis(kvm))
vgic_v4_configure_vsgis(kvm);
return 0;
diff --git a/arch/arm64/kvm/vgic/vgic-v4.c b/arch/arm64/kvm/vgic/vgic-v4.c
index e7e284d47a77..25e9da9e7a2d 100644
--- a/arch/arm64/kvm/vgic/vgic-v4.c
+++ b/arch/arm64/kvm/vgic/vgic-v4.c
@@ -245,7 +245,7 @@ int vgic_v4_init(struct kvm *kvm)
lockdep_assert_held(&kvm->arch.config_lock);
- if (!kvm_vgic_global_state.has_gicv4)
+ if (!vgic_supports_direct_irqs(kvm))
return 0; /* Nothing to see here... move along. */
if (dist->its_vm.vpes)
diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
index 4a34f7f0a864..1b4886f3fb20 100644
--- a/include/kvm/arm_vgic.h
+++ b/include/kvm/arm_vgic.h
@@ -264,6 +264,9 @@ struct vgic_dist {
/* distributor enabled */
bool enabled;
+ /* Supports SGIs without active state */
+ bool nassgicap;
+
/* Wants SGIs without active state */
bool nassgireq;
--
2.50.0.rc2.692.g299adb8693-googOn Fri, 13 Jun 2025 16:52:37 +0100,
Raghavendra Rao Ananta <rananta@google.com> wrote:
>
> KVM unconditionally advertises GICD_TYPER2.nASSGIcap (which internally
> implies vSGIs) on GICv4.1 systems. Allow userspace to change whether a
> VM supports the feature. Only allow changes prior to VGIC initialization
> as at that point vPEs need to be allocated for the VM.
>
> For convenience, bundle support for vLPIs and vSGIs behind this feature,
> allowing userspace to control vPE allocation for VMs in environments
> that may be constrained on vPE IDs.
>
> Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
> Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
> ---
> .../virt/kvm/devices/arm-vgic-v3.rst | 29 +++++++++++++++
> arch/arm64/include/uapi/asm/kvm.h | 3 ++
> arch/arm64/kvm/vgic/vgic-init.c | 3 ++
> arch/arm64/kvm/vgic/vgic-kvm-device.c | 37 +++++++++++++++++++
> arch/arm64/kvm/vgic/vgic-mmio-v3.c | 10 ++++-
> arch/arm64/kvm/vgic/vgic-v3.c | 5 ++-
> arch/arm64/kvm/vgic/vgic-v4.c | 2 +-
> include/kvm/arm_vgic.h | 3 ++
> 8 files changed, 88 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/virt/kvm/devices/arm-vgic-v3.rst b/Documentation/virt/kvm/devices/arm-vgic-v3.rst
> index e860498b1e35..049d77eae591 100644
> --- a/Documentation/virt/kvm/devices/arm-vgic-v3.rst
> +++ b/Documentation/virt/kvm/devices/arm-vgic-v3.rst
> @@ -306,3 +306,32 @@ Groups:
>
> The vINTID specifies which interrupt is generated when the vGIC
> must generate a maintenance interrupt. This must be a PPI.
> +
> + KVM_DEV_ARM_VGIC_GRP_FEATURES
> + Attributes:
> +
> + KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap
> + Control whether support for SGIs without an active state is exposed
> + to the VM. attr->addr points to a __u8 value which indicates whether
> + he feature is enabled / disabled.
s/he/the/
> +
> + A value of 0 indicates that the feature is disabled. A nonzero value
> + indicates that the feature is enabled.
> +
> + This attribute can only be set prior to initializing the VGIC (i.e.
> + KVM_DEV_ARM_VGIC_CTRL_INIT).
> +
> + Support for SGIs without an active state depends on hardware support.
> + Userspace can discover support for the feature by reading the
> + attribute after creating a VGICv3. It is possible that
> + KVM_DEV_ARM_VGIC_CTRL_INIT can later fail if this feature is enabled
> + and KVM is unable to allocate GIC vPEs for the VM.
Can you please add a sentence about the default behaviour? We
currently rely on the GICv4.1 capabilities to be available by default,
and it'd be important to capture this.
> +
> + Errors:
> +
> + ======= ========================================================
> + -ENXIO Invalid attribute in attr->attr
> + -EFAULT Invalid user address in attr->addr
> + -EBUSY The VGIC has already been initialized
> + -EINVAL KVM doesn't support the requested feature setting
> + ======= ========================================================
> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> index ed5f3892674c..41e9ce412afd 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -417,6 +417,7 @@ enum {
> #define KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO 7
> #define KVM_DEV_ARM_VGIC_GRP_ITS_REGS 8
> #define KVM_DEV_ARM_VGIC_GRP_MAINT_IRQ 9
> +#define KVM_DEV_ARM_VGIC_GRP_FEATURES 10
> #define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT 10
> #define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK \
> (0x3fffffULL << KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT)
> @@ -429,6 +430,8 @@ enum {
> #define KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES 3
> #define KVM_DEV_ARM_ITS_CTRL_RESET 4
>
> +#define KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap 0
> +
> /* Device Control API on vcpu fd */
> #define KVM_ARM_VCPU_PMU_V3_CTRL 0
> #define KVM_ARM_VCPU_PMU_V3_IRQ 0
> diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
> index 5e0e4559004b..944e24750ac4 100644
> --- a/arch/arm64/kvm/vgic/vgic-init.c
> +++ b/arch/arm64/kvm/vgic/vgic-init.c
> @@ -157,6 +157,9 @@ int kvm_vgic_create(struct kvm *kvm, u32 type)
>
> kvm->arch.vgic.in_kernel = true;
> kvm->arch.vgic.vgic_model = type;
> + if (type == KVM_DEV_TYPE_ARM_VGIC_V3)
> + kvm->arch.vgic.nassgicap = kvm_vgic_global_state.has_gicv4_1 &&
> + gic_cpuif_has_vsgi();
>
> kvm->arch.vgic.vgic_dist_base = VGIC_ADDR_UNDEF;
>
> diff --git a/arch/arm64/kvm/vgic/vgic-kvm-device.c b/arch/arm64/kvm/vgic/vgic-kvm-device.c
> index e28cf68a49c3..629f56063a13 100644
> --- a/arch/arm64/kvm/vgic/vgic-kvm-device.c
> +++ b/arch/arm64/kvm/vgic/vgic-kvm-device.c
> @@ -626,6 +626,26 @@ static int vgic_v3_set_attr(struct kvm_device *dev,
> dev->kvm->arch.vgic.mi_intid = val;
> return 0;
> }
> + case KVM_DEV_ARM_VGIC_GRP_FEATURES: {
> + u8 __user *uaddr = (u8 __user *)attr->addr;
> + u8 val;
> +
> + if (attr->attr != KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap)
> + return -ENXIO;
> +
> + if (get_user(val, uaddr))
> + return -EFAULT;
> +
> + guard(mutex)(&dev->kvm->arch.config_lock);
> + if (vgic_initialized(dev->kvm))
> + return -EBUSY;
> +
> + if (!(kvm_vgic_global_state.has_gicv4_1 && gic_cpuif_has_vsgi()) && val)
> + return -EINVAL;
> +
> + dev->kvm->arch.vgic.nassgicap = val;
> + return 0;
> + }
> default:
> return vgic_set_common_attr(dev, attr);
> }
> @@ -646,6 +666,17 @@ static int vgic_v3_get_attr(struct kvm_device *dev,
> guard(mutex)(&dev->kvm->arch.config_lock);
> return put_user(dev->kvm->arch.vgic.mi_intid, uaddr);
> }
> + case KVM_DEV_ARM_VGIC_GRP_FEATURES: {
> + u8 __user *uaddr = (u8 __user *)attr->addr;
> + u8 val;
> +
> + if (attr->attr != KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap)
> + return -ENXIO;
> +
> + guard(mutex)(&dev->kvm->arch.config_lock);
> + val = dev->kvm->arch.vgic.nassgicap;
> + return put_user(val, uaddr);
> + }
> default:
> return vgic_get_common_attr(dev, attr);
> }
> @@ -683,8 +714,14 @@ static int vgic_v3_has_attr(struct kvm_device *dev,
> return 0;
> case KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES:
> return 0;
> + default:
> + return -ENXIO;
> }
> + case KVM_DEV_ARM_VGIC_GRP_FEATURES:
> + return attr->attr != KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap ?
> + -ENXIO : 0;
Do we really want to advertise KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap even
when we don't have GICv4.1? This seems rather odd. My take on this API
is that this should report whether the feature is configurable, making
it backward compatible with older versions of KVM.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
On Sat, Jun 21, 2025 at 09:50:48AM +0100, Marc Zyngier wrote: > On Fri, 13 Jun 2025 16:52:37 +0100, Raghavendra Rao Ananta <rananta@google.com> wrote: > > @@ -683,8 +714,14 @@ static int vgic_v3_has_attr(struct kvm_device *dev, > > return 0; > > case KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES: > > return 0; > > + default: > > + return -ENXIO; > > } > > + case KVM_DEV_ARM_VGIC_GRP_FEATURES: > > + return attr->attr != KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap ? > > + -ENXIO : 0; > > Do we really want to advertise KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap even > when we don't have GICv4.1? This seems rather odd. My take on this API > is that this should report whether the feature is configurable, making > it backward compatible with older versions of KVM. So this was because of me, as I wanted nASSGIcap to behave exactly like the ID registers. I do think exposing the capability unconditionally is useful, as otherwise there's no way to definitively say whether or not the underlying platform supports GICv4.1. KVM_HAS_DEVICE_ATTR can't be used alone for probing since old kernels use GICv4.1 but don't expose the attribute. Does that make sense? Thanks, Oliver
On Mon, 23 Jun 2025 09:40:46 +0100, Oliver Upton <oliver.upton@linux.dev> wrote: > > On Sat, Jun 21, 2025 at 09:50:48AM +0100, Marc Zyngier wrote: > > On Fri, 13 Jun 2025 16:52:37 +0100, Raghavendra Rao Ananta <rananta@google.com> wrote: > > > @@ -683,8 +714,14 @@ static int vgic_v3_has_attr(struct kvm_device *dev, > > > return 0; > > > case KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES: > > > return 0; > > > + default: > > > + return -ENXIO; > > > } > > > + case KVM_DEV_ARM_VGIC_GRP_FEATURES: > > > + return attr->attr != KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap ? > > > + -ENXIO : 0; > > > > Do we really want to advertise KVM_DEV_ARM_VGIC_FEATURE_nASSGIcap even > > when we don't have GICv4.1? This seems rather odd. My take on this API > > is that this should report whether the feature is configurable, making > > it backward compatible with older versions of KVM. > > So this was because of me, as I wanted nASSGIcap to behave exactly like > the ID registers. I do think exposing the capability unconditionally is > useful, as otherwise there's no way to definitively say whether or not > the underlying platform supports GICv4.1. > > KVM_HAS_DEVICE_ATTR can't be used alone for probing since old kernels > use GICv4.1 but don't expose the attribute. > > Does that make sense? My own reasoning is that if we expose the capability, userspace is able to use it and rely on it to take effect (VPE allocation error notwithstanding). This is not the case with this approach, and that's at odds with the other attributes. But taking a step back: if we want to control the nASSGIcap bit, why don't we allow writing to GICD_TYPER2 from userspace? This does matches your view that we treat it as an ID register (GICD_TYPER2 matches this definition if you squint hard enough). It also avoids adding new UAPI with unusual semantics. Has this been considered? Thanks, M. -- Without deviation from the norm, progress is not possible.
© 2016 - 2025 Red Hat, Inc.