Red Hat Bugzilla – Bug 618788
device-assignment hangs with kvm_run: Bad address
Last modified: 2013-01-09 17:57:12 EST
Description of problem: Assigning a device with an option ROM on kernel 2.6.32-52.el6.x86_64 results in: kvm_run: Bad address kvm_run returned -14 and the guest stops Version-Release number of selected component (if applicable): kernel-2.6.32-52.el6.x86_64 qemu-kvm-0.12.1.2-2.99.el6.bz617463.x86_64 How reproducible: 100% Steps to Reproduce: 1. assign dev with option ROM 2. 3. Actual results: hang Expected results: boot Additional info:
Alex, can you please provide the use case where this error is found? I'm trying to better qualify it as a blocker, so use case of 'this specific nic device assignment failed' is desired.
Dor, any device with an option rom will generate the bad address error and cause the guest to hang, whether the option rom is needed by the guest drivers or not. This includes things like kawela and niantic physical functions, nearly any nic that supports pxe boot on the host, and various other cards. Device assignment is nearly unusable without this change. This change is only now necessary because the -52 kernel included this change from kvm.git: commit b4f8c24994f8fd8fedb304dc6aa23557fdced21c Author: Gleb Natapov <gleb@redhat.com> Date: Wed Jul 7 20:16:45 2010 +0300 KVM: Return EFAULT from kvm ioctl when guest accesses bad area Currently if guest access address that belongs to memory slot but is not backed up by page or page is read only KVM treats it like MMIO access. Remove that capability. It was never part of the interface and should not be relied upon. Signed-off-by: Gleb Natapov <gleb@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com>
*** Bug 619989 has been marked as a duplicate of this bug. ***
Reporduced on qemu-kvm-0.12.1.2-2.96.el6 Verified on qemu-kvm-0.12.1.2-2.106.el6 hw info : 28:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) CLI: /usr/libexec/qemu-kvm -S -M rhel6.0.0 -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name pci-6.64 -uuid 74b17311-f33f-8b6c-f1e5-f12f9fcd4909 -nodefconfig -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/pci-6.64.monitor,server,nowait -mon chardev=monitor,mode=control -rtc base=utc -no-reboot -boot c -kernel /var/lib/libvirt/boot/virtinst-vmlinuz.S15PWj -initrd /var/lib/libvirt/boot/virtinst-initrd.img.j5yEXp -append method=http://download.englab.nay.redhat.com/pub/rhel/rel-eng/RHEL6.0-20100722.0/6.0/Server/x86_64/os -drive file=/home/images/pci-assignment.img,if=none,id=drive-virtio-disk0,boot=on,format=raw,cache=none -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x5 -device pci-assign,host=28:00.0,id=hostdev0,configfd=18,bus=pci.0,addr=0x6 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 The guest can install successfully. Change status to verified.
Red Hat Enterprise Linux 6.0 is now available and should resolve the problem described in this bug report. This report is therefore being closed with a resolution of CURRENTRELEASE. You may reopen this bug report if the solution does not work for you.