On Thu, May 15, 2025 at 3:30 AM Ben Horgan <ben.horgan@xxxxxxx> 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
