After installing qemu + libvirt via zypper on my raspberry pi 3 with openSUSE Leap 42.3, it works with KVM good.
qemu-system-aarch64 -version says: “QEMU emulator version 2.9.1(openSUSE Leap 42.3”)
Have you checked to see whether pre-compiled packages of QEMU 2.12 might already be available?
I don’t know if anything at the following link might work for you, there is the Virtualization repo and a few home repos
The packages site says that only 2.9.1 is availiable for Leap 42.3.
Anyway, my workflow can require some custom changes to qemu code in future. I can test on official 2.9, but it would be much better to be able to build it.
It seems that for now the only way is manually adding the published patches to qemu code.
Under 42.3,
Click on “experimental packages” and “communitypackages”
You’ll find repos exist with pre-compiled version 2.12
I haven’t looked further to see if those packages include source, but you should go to <those> repos to see how they built 2.12.
If you are unable to read those repos or find they don’t have what you need, post again.
I’ve tried the source package from “Virtualization”.
After a long compilation it fails starting KVM with the same error:
Initialization of device arm_gic failed: KVM with user space irqchip only works when the host kernel supports KVM_CAP_ARM_USER_IRQ
Because full compilation on raspi takes a long time, I’ve inspected sources and patches of: openSUSE:Factory:RISCV:qemu - seems to have the same error; code around the point that throws described error is just the same. home:aevseev - seems not to contain needed changes; home:pgnd:Virtualization:qemu - seems not to contain needed changes;
Though I can’t figure out what patch fixed this error in official package. Maybe I’m messing up with configure script args, but none of them seem to be relevant to this error.
Maybe in a couple of days I’ll try to recompile openSUSE:Factory:RISCV:qemu, but I’m pretty sure the result will be the same.
You don’t have to try to do all this on your own.
Open a bug at https://bugzilla.opensuse.org and it’ll hopefully be assigned to one of the maintainers with some inside knowledge.
The error suggests that the problem might be fixed simply by enabling a kernel capability that has been disabled.
I don’t know the best way that should be addressed, I’d guess it’s likely that perhaps a kernel maintainer might be able to do a quick lookup, flip a switch and something will be available for testing quickly.
So you complain on openSUSE bugzilla that upstream does not implement some feature. What do you expect openSUSE to do with this bug report? Why do not you request addition of this feature on QEMU bugzilla/mailing list/whatever they use to track code changes?
I suppose that if the kernel has this feature - and successfull run of official 2.9.1 qemu says that it has - the system should clearly return information about it within standard ioctl method. You can find it in qemu code: file accel\kvm\kvm-all.c, function chain kvm_arm_supports_user_irq->kvm_check_extension->kvm_ioctl->ioctl. It is the only check to throw this error:
if (kvm_enabled() && !kvm_arm_supports_user_irq()) {
error_setg(errp, "KVM with user space irqchip only works when the "
"host kernel supports KVM_CAP_ARM_USER_IRQ");
return;
}
If kernel actually has not this feature, it will be very strange that special openSUSE build of qemu 2.9.1 successfully uses it. But in this case the bug should be rejected and I should go disassembly this qemu version or find another way to understand needed patches.
I don’t know if there is any certain evidence that the missing kernel capability exists upstream or not, but I feel that there are <suggestions> that it does.
Maybe it exists upstream but was disabled by the SUSE kernel maintainers, maybe not. Someone in that group would probably know, and with little effort (at least a lot less than we who don’t do stuff in that area regularly).
In any case,
You can also try to install and run a vanilla kernel (unmodified by SUSE kernel maintainers), but IIRC requires some special boot statements. U-boot (which RPi uses like most embedded system images) is odd, and doesn’t conform with the procedures you normally find booting x64. And, it might be a bit of a trick to just find a compiled vanilla kernel specific to your RPi so you don’t have to compile it.
After some disasming of opensuse aarch64 QEMU I’ve found that it really uses wrong ID (KVM_CAP_ARM_USER_IRQ == 0x1089). Searching for constants in google I’ve found this page:
#define KVM_CAP_ARM_USER_IRQ (0x1000 | 137) /* Will only be fixed in 4.12 */
Needless to say,
If you found something that has existing for awhile, the bug may be specific to what you are doing, so be sure to provide details about exactly what you are doing so that the situation is fully understood.
