Hide Forgot
Created attachment 591434 [details] guest core dump Description of problem: win7 guest crash when I disble/enable virtIO balloon device during enlarging/evicting memory and at same time qemu monitor window get a message said "(qemu) virtio_ioport_write: unexpected address 0x13 value 0x1" Version-Release number of selected component (if applicable): virtio-win-1.5.2-1.el6.noarch How reproducible: (reproduce ratio is about 60% ) step 1: Bootup windows7 guest with balloon device enabled , command like below: /usr/libexec/qemu-kvm -M rhel6.3.0 -cpu Penryn -smp 2,sockets=2,cores=1,threads=1 -m 4G -enable-kvm -uuid `uuidgen` -boot order=dnc,once=d -drive file=/usr/share/virtio-win/virtio-win-1.5.2.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1 -spice port=5904,disable-ticketing -k en-us -rtc base=localtime,driftfix=slew -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-tablet,id=input0 -drive file=/root/win7.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,serial=yzWaibVh,cache=none,werror=stop,rerror=stop,aio=native -device ide-drive,drive=drive-virtio-disk0,id=virtio-disk0 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=9a:1b:69:1a:e5:5c,bus=pci.0,addr=0x5,bootindex=3 -monitor stdio -device virtio-balloon-pci,id=balloon1,bus=pci.0,addr=0x7 -qmp tcp:0:4444,server,nowait step 2: Open "Device manager" window and install virtIO balloon device driver from CD-room in guest step 3: Execute info balloon in qemu monitor window step 4: Disabled virtIO balloon device in "Device Manager"(guest side) step 5: Execute "balloon 600" evicting memory in qemu monitor window step 6: Enabled virtIO balloon device in windows "Device Manager" window step 7: Disable virtIO balloon device in windows "Device Manager" window during evicting memory step 8: resize balloon value in qemu monitor window with "balloon 2048" repeat step5 - step8 (most of times , guest crash in step4 or step8) Actual results: sometimes, guest crashed Expected results: guest works fine, no crash happened Additional info: qemu-kvm-0.12.1.2-2.295.el6.x86_64 qemu-kvm-tools-0.12.1.2-2.295.el6.x86_64 kernel-2.6.32-278.el6.x86_64 guest: en_windows_7_ultimate_x64
> (qemu) virtio_ioport_write: unexpected address 0x13 value 0x1" This means the driver is trying to write to a read-only address, VIRTIO_PCI_ISR. Linux guests never write to this address. Looks like the Windows PCI driver does, and that's a bug.
Postponed to RHEL6.5, due to capacity constraints, and under the assumption that no customer is using virtio-win ballooning.
please recheck with the latest driver from build 35 http://download.devel.redhat.com/brewroot/packages/virtio-win-prewhql/0.1/35/win/virtio-win-prewhql-0.1.zip
Verified the bug on (In reply to comment #5) > please recheck with the latest driver from build 35 > http://download.devel.redhat.com/brewroot/packages/virtio-win-prewhql/0.1/35/ > win/virtio-win-prewhql-0.1.zip Reproduced this issue on virtio-win-1.5.2 Verified the bug on virtio-win-prewhql-0.1-35 Start guest, /usr/libexec/qemu-kvm -cpu Penryn -smp 2 -m 4G -enable-kvm -uuid `uuidgen` -spice port=5931,disable-ticketing -k en-us -rtc base=localtime,driftfix=slew -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device usb-tablet,id=input0 -drive file=/home/win7-64-725-active.raw,if=none,id=drive-virtio-disk0,format=raw,serial=yzWaibVh,cache=none,werror=stop,rerror=stop,aio=native -device ide-drive,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,id=hostnet0,vhost=on -device e1000,netdev=hostnet0,id=net0,mac=9a:1b:69:1a:e5:5c,bus=pci.0,addr=0x5,bootindex=3 -monitor stdio -device virtio-balloon-pci,id=balloon1,bus=pci.0,addr=0x7 -qmp tcp:0:4444,server,nowait Steps, repeat steps 5-8 from comments 0 Actual Results: on virtio-win-1.5.2 ,guest got BSOD. on virtio-win-prewhql-0.1-35,guest works well without error. Based on above ,this issue has been fixed already ,move status to VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0441.html