[libvirt] [RFC v3 PATCH 0/5] PowerPC : Extend libvirt for the PowerPC-KVM platform

Tue Nov 29 16:39:09 UTC 2011

On 11/29/2011 09:55 AM, Prerna Saxena wrote:
> Recent development in KVM for 64-bit Power ISA Book3S machines, allows
> users to run multiple KVM guest instances on POWER7 and PPC970
> processor based systems.  Also qemu-system-ppc64 has been enhanced to
> support a new machine type "pseries" suitable for Power Book3S machines.
> This addition effectively brings the KVM+qemu combination to run
> multiple guest instances on a Power Book3S machine.

I applied this patch series on an x86 machine and ran 'make check'. I 
now have two tests failing due to it not making use of the proc 
filesystem entries anymore...

TEST: nodeinfotest
       Expect 39 'CPUs: 2, MHz: 2800, Nodes: 1, Cores: 2
'
Actual 39 'CPUs: 8, MHz: 2800, Nodes: 1, Cores: 4
'
!Expect 39 'CPUs: 2, MHz: 2211, Nodes: 1, Cores: 2
'
Actual 39 'CPUs: 8, MHz: 2211, Nodes: 1, Cores: 4
'
!Expect 39 'CPUs: 4, MHz: 1595, Nodes: 1, Cores: 2
'
Actual 39 'CPUs: 8, MHz: 1595, Nodes: 1, Cores: 4
'
!Expect 39 'CPUs: 4, MHz: 1000, Nodes: 1, Cores: 4
'
Actual 39 'CPUs: 8, MHz: 1000, Nodes: 1, Cores: 4
'
!Expect 39 'CPUs: 4, MHz: 2814, Nodes: 1, Cores: 2
'
Actual 39 'CPUs: 8, MHz: 2814, Nodes: 1, Cores: 4
'
!Expect 39 'CPUs: 4, MHz: 1000, Nodes: 1, Cores: 2
'
Actual 39 'CPUs: 8, MHz: 1000, Nodes: 1, Cores: 4
'
!                                   6   FAIL
FAIL: nodeinfotest
[...]
TEST: qemuargv2xmltest
       /bin/sh: line 5:   875 Segmentation fault      (core dumped) 
abs_top_builddir=`cd '..'; pwd` abs_top_srcdir=`cd '..'; pwd` 
abs_builddir=`pwd` abs_srcdir=`cd '.'; pwd` CONFIG_HEADER="`cd '..'; 
pwd`/config.h" PATH="`cd '..'; pwd`/daemon:`cd '..'; pwd`/tools:`cd 
'..'; pwd`/tests:$PATH" SHELL="/bin/sh" 
LIBVIRT_DRIVER_DIR="/root/tmp/libvirt-acl/src/.libs" LC_ALL=C ${dir}$tst
FAIL: qemuargv2xmltest

I had 'export DEBUG_TESTS=1' set to see the debugging info on the 
nodeinfo test.

The qemuargv2xmltest fails due to the following:

0x00000038ec32e334 in __strcmp_ssse3 () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install 
augeas-libs-0.9.0-1.fc14.x86_64 avahi-libs-0.6.27-8.fc14.x86_64 
cyrus-sasl-lib-2.1.23-12.fc14.x86_64 dbus-libs-1.4.0-3.fc14.x86_64 
device-mapper-libs-1.02.63-2.fc14.x86_64 glibc-2.13-2.x86_64 
gnutls-2.8.6-2.fc14.x86_64 keyutils-libs-1.2-6.fc12.x86_64 
krb5-libs-1.8.4-2.fc14.x86_64 libcap-ng-0.6.5-1.fc14.x86_64 
libcom_err-1.41.12-6.fc14.x86_64 libcurl-7.21.0-10.fc14.x86_64 
libgcc-4.5.1-4.fc14.x86_64 libgcrypt-1.4.5-4.fc13.x86_64 
libgpg-error-1.9-1.fc14.x86_64 libidn-1.18-1.fc14.x86_64 
libpcap-1.1.1-3.fc14.x86_64 libselinux-2.0.96-6.fc14.1.x86_64 
libsepol-2.0.41-3.fc14.x86_64 libssh2-1.2.4-1.fc14.x86_64 
libtasn1-2.7-1.fc14.x86_64 libudev-161-10.fc14.x86_64 
libxml2-2.7.7-3.fc14.x86_64 libxslt-1.1.26-3.fc14.x86_64 
netcf-libs-0.1.9-1.fc14.x86_64 nspr-4.8.8-1.fc14.x86_64 
nss-3.12.10-4.fc14.x86_64 nss-softokn-freebl-3.12.10-1.fc14.x86_64 
nss-util-3.12.10-1.fc14.x86_64 numactl-2.0.3-8.fc13.x86_64 
openldap-2.4.23-10.fc14.x86_64 openssl-1.0.0e-1.fc14.x86_64 
xen-libs-4.0.2-1.fc14.x86_64 yajl-1.0.7-3.fc13.x86_64 
zlib-1.2.5-2.fc14.x86_64
(gdb) up
#1  0x000000000042d56c in qemuParseCommandLine (caps=0x9b94a0, 
progenv=0x9badc0, progargv=0x9bae00, pidfile=0x0, monConfig=0x0, 
monJSON=0x0)
     at qemu/qemu_command.c:6694
6694        if (STREQ(def->os.arch, "i686")||STREQ(def->os.arch, "x86_64"))
(gdb) print def->os
$1 = {type = 0x0, arch = 0x0, machine = 0x0, nBootDevs = 0, bootDevs = 
{0, 0, 0, 0}, bootmenu = 0, init = 0x0, kernel = 0x0, initrd = 0x0,
   cmdline = 0x0, root = 0x0, loader = 0x0, bootloader = 0x0, 
bootloaderArgs = 0x0, smbios_mode = 0, bios = {useserial = 0}}

I looked on a RHEL 5 machine (i686). The sysfs at least is there.

     Stefan

> Libvirt continues to be the key interface to configure and manage the
> KVM guest instances on x86.  This patch set is an effort to enable
> libvirt to support KVM guest configuration and management on Power Book3S
> machines.
>
> Based on community discussion around the earlier version, this patch
> series augments the present 'kvm' driver to support PowerPC-KVM based
> guests.Since some of the supported devices vary between architectures,
> libvirt must be capable of choosing supported device backends and
> defaults for each architecture in qemu.
>
> To check if qemu supports a certain feature, libvirt at present parses
> the -help string which is generated by running the qemu binary with the
> '-h' argument. This approach is gated by QEMU's inherent limitation.
> When generating the list of allowed options with the '-h' flags, qemu
> today blindly lists all options defined for any architecture/platform
> instead of doing any arch-specific checking. This tricks libvirt into
> assuming a much bigger set of host capabilities than is actually
> available.
> Ideally, it would be good to have qemu specify a list of devices for a
> given architecture and platform which libvirt can parse to understand
> supported capabilities for that guest.
>
> As a part of this patchset, there is an attempt to cleanly bifurcate
> libvirt code and to remove x86-specific assumptions from generic qemu
> commandline code.
>
> Series Description:
> -------------------
> This patch series consists of 5 patches :
> Patch 1/5 : Use sysfs to gather host topology in place of /proc/cpuinfo.
> Patch 2/5 : Add PowerPC CPU Driver
> Patch 3/5 : Add support for qemu-system-ppc64
> Patch 4/5 : Clean up x86-specific assumptions from generic qemu code.
> Patch 5/5 : Add address family "spapr-vio"
>
> Changelog:
> ---------
> ** v1->v2 :
> * Patches 1,2,3 unchanged ; The hacks in Patch 4 of v1 replaced by a
>    new patch to neatly select arch-specific features.
>
> ** v2->v3 :
> * Patches 1,2,3 have minor cleanups ; Patch 4 no longer has an
>    arch-specific handler routine. It is now replaced by a much simpler
>    patch that merely removes x86/pc-specific assumptions from libvirt.
>
> ** v3->v4 :
> * Patches 1,2,3,4 unchanged ; patch 5 is a new addition from Michael Ellerman
>    that adds a new device-tree based addressing mechanism for the 'pseries'
>    guest.
>
>