On Tue, 5 Sept 2023 at 15:56, Philippe Mathieu-Daudé <[email protected]> wrote: > > Simplify gicv3_class_name() logic. No functional change intended. > > Signed-off-by: Philippe Mathieu-Daudé <[email protected]> > --- > hw/intc/arm_gicv3_common.c | 9 ++++----- > 1 file changed, 4 insertions(+), 5 deletions(-) > > diff --git a/hw/intc/arm_gicv3_common.c b/hw/intc/arm_gicv3_common.c > index 2ebf880ead..8863f06b67 100644 > --- a/hw/intc/arm_gicv3_common.c > +++ b/hw/intc/arm_gicv3_common.c > @@ -612,13 +612,12 @@ type_init(register_types) > > const char *gicv3_class_name(void) > { > - if (kvm_irqchip_in_kernel()) { > - return "kvm-arm-gicv3"; > - } else { > - if (kvm_enabled()) { > + if (kvm_enabled()) { > + if (!kvm_irqchip_in_kernel()) { > error_report("Userspace GICv3 is not supported with KVM"); > exit(1); > } > - return "arm-gicv3"; > + return "kvm-arm-gicv3"; > } > + return "arm-gicv3"; > }
This doesn't seem to me to be obviously clearer or simpler than the current code, which is the same basic logic as the GICv2 gic_class_name(), but with the extra condition of "report the error for the case we don't support yet". In particular the major condition for "should we be using kvm-arm-gicv3" is not "are we using KVM?" but "are we using the KVM in-kernel irqchip?". thanks -- PMM
