Bug 1171501
| Summary: | Cubietruck: cannot create KVM guests: "kvm_init_vcpu failed: Invalid argument" | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kashyap Chamarthy <kchamart> |
| Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | amit.shah, berrange, cfergeau, crobinso, dwmw2, itamar, mbooth, pbonzini, ptoscano, rbalakri, rjones, scottt.tw, virt-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | armv7hl | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-12-09 17:35:51 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Kashyap Chamarthy
2014-12-07 19:46:21 UTC
From the inter-webs, seems like this is a reasonably popular error for ARM and KVM. I stumbled on a thread (Tue Dec 10 09:39:09 UTC 2013) on fedora-arm list: https://lists.fedoraproject.org/pipermail/arm/2013-December/007155.html uboot with hyp mode support now available for the cubietruck Quoting Richard Jones from the above email: "I can confirm this works at least as far as running libguestfs appliances using KVM. I had to use the attached hack to make qemu create Cortex-A7 guests, otherwise you get the following error": kvm_init_vcpu failed: Invalid argument ------------------------------------------------- diff --git a/target-arm/kvm.c b/target-arm/kvm.c index 6e5cd36..48b2773 100644 --- a/target-arm/kvm.c +++ b/target-arm/kvm.c @@ -86,7 +86,7 @@ int kvm_arch_init_vcpu(CPUState *cs) struct kvm_reg_list *rlp; ARMCPU *cpu = ARM_CPU(cs); - init.target = KVM_ARM_TARGET_CORTEX_A15; + init.target = KVM_ARM_TARGET_CORTEX_A7; /* XXX HACK */ memset(init.features, 0, sizeof(init.features)); ret = kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, &init); if (ret) { For some reason I thought this had been fixed upstream, but
now that I've finally got my CT working again, I see that I
am still carrying that patch in my custom qemu.
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index 5ce7350..04d69d1 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -858,7 +858,7 @@ static void cortex_a15_initfn(Object *obj)
set_feature(&cpu->env, ARM_FEATURE_DUMMY_C15_REGS);
set_feature(&cpu->env, ARM_FEATURE_CBAR_RO);
set_feature(&cpu->env, ARM_FEATURE_LPAE);
- cpu->kvm_target = QEMU_KVM_ARM_TARGET_CORTEX_A15;
+ cpu->kvm_target = QEMU_KVM_ARM_TARGET_CORTEX_A7;
cpu->midr = 0x412fc0f1;
cpu->reset_fpsid = 0x410430f0;
cpu->mvfr0 = 0x10110222;
So that's the answer really, it's a qemu bug. Actually it looks as
if qemu contains some code to try to get the host CPU type, but it
doesn't work, or maybe we need to pass a -cpu option ...
This is fixed in libguestfs with this commit (committed in upstream git): https://github.com/libguestfs/libguestfs/commit/6468b9d60172bcef76b36c14b72f9a1913d94954 arm: Use -cpu host on KVM. With the above commit applied, KVM guest (a libguestfs appliance) successfully boots on Cubietruck: . . . [01433ms] /bin/qemu-system-arm \ -global virtio-blk-device.scsi=off \ -nodefconfig \ -enable-fips \ -nodefaults \ -display none \ -M vexpress-a15 \ -cpu host \ -machine accel=kvm:tcg \ -m 500 \ -no-reboot \ -rtc driftfix=slew \ -global kvm-pit.lost_tick_policy=discard \ -kernel /home/kashyapc/src/libguestfs/tmp/.guestfs-1000/appliance.d/kernel \ -dtb /home/kashyapc/src/libguestfs/tmp/.guestfs-1000/appliance.d/dtb \ -initrd /home/kashyapc/src/libguestfs/tmp/.guestfs-1000/appliance.d/initrd \ -device virtio-scsi-device,id=scsi \ -drive file=/home/kashyapc/src/libguestfs/tmp/libguestfsRMfHzO/scratch.1,cache=unsafe,format=raw,id=hd0,if=none \ -device scsi-hd,drive=hd0 \ -drive file=/home/kashyapc/src/libguestfs/tmp/.guestfs-1000/appliance.d/root,snapshot=on,id=appliance,cache=unsafe,if=none \ -device scsi-hd,drive=appliance \ -device virtio-serial-device \ -serial stdio \ -chardev socket,path=/home/kashyapc/src/libguestfs/tmp/libguestfsRMfHzO/guestfsd.sock,id=channel0 \ -device virtserialport,chardev=channel0,name=org.libguestfs.channel.0 \ -append 'panic=1 mem=500M console=ttyAMA0 udevtimeout=6000 udev.event-timeout=6000 no_timer_check acpi=off printk.time=1 cgroup_disable=memory root=/dev/sdb selinux=0 guestfs_verbose=1 TERM=vt102' . . . Some more context on this upstream QEMU mailing list thread: http://lists.nongnu.org/archive/html/qemu-devel/2014-12/msg01093.html Yup, all good now so let's close this bug. |