Bug 1002066 - CPU model checking code is broken wrt TCG guests
Summary: CPU model checking code is broken wrt TCG guests
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Jiri Denemark
QA Contact:
: 996007 (view as bug list)
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs libvirtCPUconfig
TreeView+ depends on / blocked
Reported: 2013-08-28 12:34 UTC by Daniel Berrangé
Modified: 2016-04-10 13:38 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-04-10 13:38:06 UTC

Attachments (Terms of Use)

Description Daniel Berrangé 2013-08-28 12:34:03 UTC
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'>
  <memory unit='KiB'>2097152</memory>
  <vcpu placement='static'>1</vcpu>
    <type arch='ppc64' machine='pseries'>hvm</type>


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

Comment 1 Jiri Denemark 2013-08-28 13:24:52 UTC
Moreover, checking compatibility between host CPU and guest CPU is completely bogus for TCG too.

Comment 2 Cole Robinson 2014-01-16 22:06:32 UTC
*** Bug 996007 has been marked as a duplicate of this bug. ***

Comment 3 Cole Robinson 2016-04-10 13:38:06 UTC
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

Note You need to log in before you can comment on or make changes to this bug.