Bug 1002066
| Summary: | CPU model checking code is broken wrt TCG guests | ||
|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Daniel Berrangé <berrange> |
| Component: | libvirt | Assignee: | Jiri Denemark <jdenemar> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | unspecified | CC: | crobinso, jdenemar, rbalakri, rjones |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-04-10 13:38:06 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 910269, 1199452 | ||
Moreover, checking compatibility between host CPU and guest CPU is completely bogus for TCG too. *** Bug 996007 has been marked as a duplicate of this bug. *** I suspect the original report of using x86 CPU bits for PPC is long since fixed. The general bogus-ness of comparing against the host CPU for TCG was fixed by:
commit 445a09bdc96ca6e434bfdcca75752ee316289bbe
Author: Cole Robinson <crobinso>
Date: Tue Sep 23 13:07:09 2014 -0400
qemu: Don't compare CPU against host for TCG
|
Description of problem: I am attempting to boot a PPC64 guest on an x86_64 host, using libvirt. The guest XML contains: <domain type='qemu'> <name>ppcdemo</name> <uuid>1ccfd97d-5eb4-478a-bbe6-88d254c16db7</uuid> <memory unit='KiB'>2097152</memory> <vcpu placement='static'>1</vcpu> <os> <type arch='ppc64' machine='pseries'>hvm</type> </os> <cpu> <model>POWER7</model> </cpu> .... </domain> So libvirt clearly knows this is a ppc64 guest with a requested PPC CPU model. QEMU knows about this CPU model. Libvirt will always fail to boot: $ virsh start ppcdemo error: Failed to start domain ppcdemo error: internal error: Unknown CPU model POWER7 The libvirtd logs meanwhile say... 2013-08-28 12:25:22.847+0000: 8715: error : x86ModelFromCPU:827 : internal error: Unknown CPU model POWER7 ....huh, it is looking for an x86 model ?!?!?! The call trace is this (gdb) bt #0 x86ModelFromCPU (cpu=cpu@entry=0x7f182c0068f0, map=map@entry=0x7f181000c410, policy=policy@entry=1) at cpu/cpu_x86.c:820 #1 0x00007f184cc3aaf1 in x86Compute (host=0x7f182c0068f0, cpu=0x7f181000c230, guest=0x7f183bcff0c0, message=0x7f183bcff0d0) at cpu/cpu_x86.c:1210 #2 0x00007f1833201e32 in qemuBuildCpuArgStr (migrating=false, hasHwVirt=<synthetic pointer>, opt=0x7f183bcff098, hostarch=<optimized out>, qemuCaps=0x7f18100318a0, emulator=0x7f180c000e90 "/home/berrange/usr/qemu-git/bin/qemu-system-ppc64", def=0x7f180c00ce30, driver=0x7f182c07a740) at qemu/qemu_command.c:6368 #3 qemuBuildCommandLine (conn=conn@entry=0x7f1824006280, driver=driver@entry=0x7f182c07a740, def=0x7f180c00ce30, monitor_chr=0x7f181000baf0, monitor_json=<optimized out>, qemuCaps=0x7f18100318a0, migrateFrom=migrateFrom@entry=0x0, migrateFd=migrateFd@entry=-1, snapshot=snapshot@entry=0x0, vmop=vmop@entry=VIR_NETDEV_VPORT_PROFILE_OP_CREATE, callbacks=0x7f18334c3a30 <buildCommandLineCallbacks>) at qemu/qemu_command.c:7462 #4 0x00007f183322ed41 in qemuProcessStart (conn=conn@entry=0x7f1824006280, driver=driver@entry=0x7f182c07a740, vm=vm@entry=0x7f182c201140, migrateFrom=migrateFrom@entry=0x0, stdin_fd=stdin_fd@entry=-1, stdin_path=stdin_path@entry=0x0, snapshot=snapshot@entry=0x0, vmop=vmop@entry=VIR_NETDEV_VPORT_PROFILE_OP_CREATE, flags=flags@entry=1) at qemu/qemu_process.c:3723 #5 0x00007f183327c7f3 in qemuDomainObjStart (conn=0x7f1824006280, driver=driver@entry=0x7f182c07a740, vm=vm@entry=0x7f182c201140, flags=flags@entry=0) at qemu/qemu_driver.c:6007 #6 0x00007f183327cde2 in qemuDomainCreateWithFlags (dom=0x7f1810031830, flags=0) at qemu/qemu_driver.c:6059 #7 0x00007f184cc6ed97 in virDomainCreate (domain=domain@entry=0x7f1810031830) at libvirt.c:9434 #8 0x00007f184d6d03b7 in remoteDispatchDomainCreate (server=<optimized out>, msg=<optimized out>, args=<optimized out>, rerr=0x7f183bcffc80, client=0x7f184e9867d0) at remote_dispatch.h:2888 #9 remoteDispatchDomainCreateHelper (server=<optimized out>, client=0x7f184e9867d0, msg=<optimized out>, rerr=0x7f183bcffc80, args=<optimized out>, ret=<optimized out>) at remote_dispatch.h:2866 #10 0x00007f184cccf13a in virNetServerProgramDispatchCall (msg=0x7f184e988ee0, client=0x7f184e9867d0, server=0x7f184e9695f0, prog=0x7f184e982df0) at rpc/virnetserverprogram.c:435 #11 virNetServerProgramDispatch (prog=0x7f184e982df0, server=server@entry=0x7f184e9695f0, client=0x7f184e9867d0, msg=0x7f184e988ee0) at rpc/virnetserverprogram.c:305 #12 0x00007f184ccc9178 in virNetServerProcessMsg (msg=<optimized out>, prog=<optimized out>, client=<optimized out>, srv=0x7f184e9695f0) at rpc/virnetserver.c:165 #13 virNetServerHandleJob (jobOpaque=<optimized out>, opaque=0x7f184e9695f0) at rpc/virnetserver.c:186 #14 0x00007f184cbd2165 in virThreadPoolWorker (opaque=opaque@entry=0x7f184e8e9410) at util/virthreadpool.c:144 #15 0x00007f184cbd17be in virThreadHelper (data=<optimized out>) at util/virthreadpthread.c:161 #16 0x00007f1849e49c53 in start_thread (arg=0x7f183bd00700) at pthread_create.c:308 #17 0x00007f184976fccd in clone () from /lib64/libc.so.6 The cpuGuestData call (which is between frames 2/3 above, seems to be where it started to go wrong. It uses the host CPU architecture to decide what driver to use. While this may be suitable for KVM, it is totally bogus for TCG where guest CPU has no relation to host CPUs. We need to break the assumption that host arch == guest arch for TCG. Version-Release number of selected component (if applicable): libvirt-client-1.1.1-1.fc19.x86_64 and git master