Bug 1063799 - VDSM for ppc64 needs qemu 1.6
Summary: VDSM for ppc64 needs qemu 1.6
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: vdsm
Version: 3.4
Hardware: ppc64
OS: Linux
unspecified
unspecified
Target Milestone: ---
: 3.5.0
Assignee: Vitor de Lima
QA Contact: Pavel Stehlik
URL:
Whiteboard: virt
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-11 13:05 UTC by Vitor de Lima
Modified: 2016-02-10 19:47 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-22 14:01:28 UTC
oVirt Team: Virt


Attachments (Terms of Use)

Description Vitor de Lima 2014-02-11 13:05:37 UTC
Description of problem:
VDSM for ppc64 must run with a newer version of qemu, otherwise an error related to the Virtual USB host device occurs.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Configure a Data Center, Cluster, Host and VM for the ppc64 architecture in  oVirt engine
2. Run the created VM

Actual results:
QEMU crashes with the following error:

qemu-system-ppc64: -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:16:01:51,bus=pci,addr=0x1: PCI: slot 1 function 0 not available for virtio-net-pci, in use by pci-ohci
qemu-system-ppc64: -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:16:01:51,bus=pci,addr=0x1: Device 'virtio-net-pci' could not be initialized

Expected results:
The VM runs normally.

Additional info:
This PCI address conflict was fixed in QEMU 1.6, but in QEMU 1.4.2 (the version shipped with Fedora) it occurs.

Comment 1 Dan Kenigsberg 2014-02-11 13:30:05 UTC
Can this fix be backported to Fedora 19's qemu?

If not, I would not mind adding an explicit spec-file dependency (for the ppc64 arch).

Comment 2 Richard W.M. Jones 2014-02-12 11:46:21 UTC
Adding Cole as he is the maintainer of qemu in Fedora.

If there is a well-defined patch that cleanly applies to
qemu, then you will need to open a bug against component=qemu &
product=Fedora, and link it to this bug.

Comment 3 Vitor de Lima 2014-02-12 13:05:10 UTC
This error can be reproduced in QEMU using the command line:

/usr/bin/qemu-system-ppc64 -machine pseries,accel=tcg,usb=off -m 1024 -smp 1,sockets=1,cores=1,threads=1 -no-user-config -nodefaults -no-shutdown -device spapr-vscsi,id=scsi0,reg=0x2000 -device virtio-scsi-pci,id=scsi1,bus=pci,addr=0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci,addr=0x4 -usb -drive if=none,id=drive-scsi0-0-0-0,readonly=on,format=raw,serial= -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 -netdev user,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:fa:c3:90,bus=pci,addr=0x1 -device usb-tablet,id=input0 -vnc 0:0 -k en-us -vga std -device virtio-balloon-pci,id=balloon0,bus=pci,addr=0x6 -usbdevice keyboard

@Cole, do you have any idea why the PCI slot 1 is free in QEMU 1.6.0 and occupied by pci-ohci in QEMU 1.4.2?

Comment 4 Cole Robinson 2014-02-12 14:38:37 UTC
I don't know offhand, git log doesn't show anything obvious. someone would have to bisect. Hopefully not a case of -M pseries changing ABI since maching types are supposed to be stable.

Comment 5 Vitor de Lima 2014-02-12 16:35:42 UTC
I found some extra info in this issue, if I call qemu like this:

/usr/bin/qemu-system-ppc64 -machine pseries,accel=tcg,usb=off -m 1024 -smp 1,sockets=1,cores=1,threads=1 -no-user-config -nodefaults -no-shutdown -device spapr-vscsi,id=scsi0,reg=0x2000 -device virtio-scsi-pci,id=scsi1,bus=pci,addr=0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci,addr=0x4 -usb -drive if=none,id=drive-scsi0-0-0-0,readonly=on,format=raw,serial= -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 -netdev user,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:fa:c3:90,bus=pci,addr=0x1 -device usb-tablet,id=input0 -vnc 0:0 -k en-us -vga std -device virtio-balloon-pci,id=balloon0,bus=pci,addr=0x6 -usbdevice keyboard

The error occurs, but if I replace '-vga std' with '-device VGA', the guest starts properly:

/usr/bin/qemu-system-ppc64 -machine pseries,accel=tcg,usb=off -m 1024 -smp 1,sockets=1,cores=1,threads=1 -no-user-config -nodefaults -no-shutdown -device spapr-vscsi,id=scsi0,reg=0x2000 -device virtio-scsi-pci,id=scsi1,bus=pci,addr=0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci,addr=0x4 -usb -drive if=none,id=drive-scsi0-0-0-0,readonly=on,format=raw,serial= -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0 -netdev user,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:fa:c3:90,bus=pci,addr=0x1 -device usb-tablet,id=input0 -vnc 0:0 -k en-us -device VGA,id=video0,bus=pci,addr=0x7 -device virtio-balloon-pci,id=balloon0,bus=pci,addr=0x6 -usbdevice keyboard

Probably it has something to do with this code in spapr.c in the QEMU source code:

    if (usb_enabled(spapr->has_graphics)) {
        pci_create_simple(phb->bus, -1, "pci-ohci");
        if (spapr->has_graphics) {
            usbdevice_create("keyboard");
            usbdevice_create("mouse");
        }
    }

Comment 6 Sandro Bonazzola 2014-03-04 09:19:02 UTC
This is an automated message.
Re-targeting all non-blocker bugs still open on 3.4.0 to 3.4.1.

Comment 7 Sandro Bonazzola 2014-05-08 13:55:39 UTC
This is an automated message.

oVirt 3.4.1 has been released.
This issue has been retargeted to 3.5.0 since it has not been marked as high priority or severity issue, please retarget if needed.

Comment 8 Michal Skrivanek 2014-08-22 14:01:28 UTC
let's not waste time on F19 anymore, it's old and about to be EOL soon
Fixed in F20+ so no need to track anymore


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