On Tue, 2018-05-15 at 12:53 +0200, Lubomir Rintel wrote: > Other "virt" type machines don't support it. > > Signed-off-by: Lubomir Rintel <lkundrak@xxxxx> > --- > src/qemu/qemu_domain.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c > index 97633bfbb9..db73f45204 100644 > --- a/src/qemu/qemu_domain.c > +++ b/src/qemu/qemu_domain.c > @@ -3044,6 +3044,7 @@ qemuDomainDefEnableDefaultFeatures(virDomainDefPtr def, > * was not included in the domain XML, we need to choose a suitable > * GIC version ourselves */ > if ((def->features[VIR_DOMAIN_FEATURE_GIC] == VIR_TRISTATE_SWITCH_ABSENT && > + def->os.arch == VIR_ARCH_AARCH64 && > qemuDomainIsVirt(def)) || > (def->features[VIR_DOMAIN_FEATURE_GIC] == VIR_TRISTATE_SWITCH_ON && > def->gic_version == VIR_GIC_VERSION_NONE)) { The check should include VIR_ARCH_ARMV7L, but that's beside the point. The thing is, up until now qemuDomainIsVirt() has been used to check whether the guest uses the armv7/aarch64 virt machine type, but now that RISC-V introduced its own virt machine type there is a lot of potential for confusion. IMHO the only sane way to deal with it is to rename the existing function to qemuDomainIsArmVirt(), and introduce a new qemuDomainIsRiscvVirt() specific to RISC-V. That will lead to a lot of places where you have to call both, but it will also ensure changes intended to one architecture don't end up affecting the other. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list