[Qemu-devel] Balloon Driver : Observation
Hi, I am observing a strange phenomenon with balloon using KVM as hypervisor. I set balloon value to an arbitratrilylow value so that the guest system is out of memory. The VM freezes therafter. But if Iquery the balloon status through qmp-shell, the qmp interface interacts with the balloon target in guest as usual. I can also reset the balloon size to its default. But the problem is that the VM still remain unresponsive. So i am not able to figure out how the guest balloon driver seem to function even though the VM has freezed. Regards
Re: [Qemu-devel] Balloon Driver : Observation
On Mon, Jun 24, 2013 at 8:31 PM, Saptarshi Sen saptarshi@gmail.com wrote: Hi, I am observing a strange phenomenon with balloon using KVM as hypervisor. I set balloon value to an arbitratrilylow value so that the guest system is out of memory. The VM freezes therafter. But if Iquery the balloon status through qmp-shell, the qmp interface interacts with the balloon target in guest as usual. I can also reset the balloon size to its default. But the problem is that the VM still remain unresponsive. So i am not able to figure out how the guest balloon driver seem to function even though the VM has freezed. The qmp balloon commands interface with the virtual hardware. Whether the guest is frozen or not does not prevent you from altering the registers in the virtual hardware. Regards, Anthony Liguori Regards
Re: [Qemu-devel] balloon driver on winxp guest start failed
On 10/17/2011 08:55 PM, Vadim Rozenfeld wrote: On Fri, 2011-10-14 at 17:49 +0800, hkran wrote: On 10/14/2011 04:55 AM, Vadim Rozenfeld wrote: On Thu, 2011-10-13 at 15:47 +0100, Stefan Hajnoczi wrote: On Thu, Oct 13, 2011 at 5:00 AM, hkranhk...@vnet.linux.ibm.com wrote: On 10/12/2011 07:09 PM, hkran wrote: I used balloon driver for windows virtio-win-0.1-15.iso (from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/) following the install guard , I installed the balloon driver like this: devcon.exe install d:\wxp\x86\balloon.inf PCI\VEN_1AF4DEV_1002SUBSYS_00051AF4REV_00 then reboot guest Os, but the status of driver installed is always incorrect, that show me the driver start failed (code 10) in the device manager. Seems like a resource allocation problem I typed the following cmds in the monitor command line: (qemu) device_add virtio-balloon (qemu) info balloon balloon: actual=2048 (qemu) balloon 1024 (qemu) info balloon balloon: actual=2048 (qemu) info balloon balloon: actual=2048 And I also tried it by using qemu -balloon virtio param when getting qemu up, the status is worse, the winxp guest froze at boot screen. Am I using balloon driver in a correct way? For the boot failure case, I take more looks into it. I open the trace output and see the following when boot failed Balloon driver, built on Oct 13 2011 10:46:59 ^M-- DriverEntry ^Mfile z:\source\kvm-guest-drivers-windows\balloon\sys\driver.c line 151 ^M-- BalloonDeviceAdd ^M-- BalloonDeviceAdd ^M-- BalloonEvtDevicePrepareHardware ^M- Port Resource [C0A0-C0C0] ^M-- BalloonEvtDevicePrepareHardware ^M-- BalloonEvtDeviceD0Entry ^M-- BalloonInit ^M-- VIRTIO_BALLOON_F_STATS_VQ ^M-- BalloonInit ^M-- BalloonInterruptEnable ^M-- BalloonInterruptEnable here, the system is blocked. I compare it with the logfile in the normal case that I hot-plugin the balloon device, and then find the system blocked before calling at BalloonInterruptDpc. What about ISR? Can you try changing balloon size and check if balloon ISR was invoked or not? Is it meaning that we open the interrupt of balloon device too soon when booting the system? I suggest CCing Vadim on virtio Windows driver questions. Not sure if he sees every qemu-devel email. Stefan To make the issue clearer, I do more tests about that. Now I use the package virtio-win-prewhql-0.1-15-sources.zip from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/ The problem that the balloon driver status is incorrect was not reproduced any longer, but boot failure still be there. more tests told me as if the failure will occur only in the case where virtio-serial and balloon are all attached when qemu booting: (qemu) [huikai@oc0100708617 ~]$ /home/huikai/qemu15/bin/qemu-system-x86_64 --enable-kvm -m 2048 -drive file=/home/huikai/xp_shanghai.img,if=virtio -net user -net nic,model=viga qxl -localtime -chardev stdio,id=muxstdio -mon chardev=muxstdio -usb -usbdevice tablet -device virtio-serial,id=vs0 -chardev socket,path=/tmp/foo,server,nowait,id=foo -device virtserialport,bus=vs0.0,chardev=foo,name=helloworld -serial file:/tmp/xp_1014_6.log -balloon virtio,id=ball1 the trace: Virtio-Serial driver started...built on Oct 14 2011 15:58:02 ^M-- VIOSerialEvtDeviceAdd ^M-- VIOSerialInitInterruptHandling ^MBalloon driver, built on Oct 13 2011 17:34:56 ^M-- DriverEntry ^M-- BalloonDeviceAdd ^M-- BalloonDeviceAdd ^M-- BalloonEvtDevicePrepareHardware ^M- Port Resource [C0A0-C0C0] ^M-- BalloonEvtDevicePrepareHardware ^M-- BalloonEvtDeviceD0Entry ^M-- BalloonInit ^M-- VIRTIO_BALLOON_F_STATS_VQ ^M-- BalloonInit ^M-- BalloonInterruptEnable ^M-- BalloonInterruptEnable ^M-- VIOSerialEvtDevicePrepareHardware ^MIO Port Info [C080-C0A0] ^MWe have multiport host ^MVirtIOConsoleConfig-max_nr_ports 31 ^M-- VIOSerialEvtDeviceD0Entry ^M-- VIOSerialInitAllQueues ^M-- VIOSerialFillQueue ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89B13A50 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89B13638 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C07E08 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C07C50 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C07A98 ... ... ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89BD14B8 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89B826E8 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89BE4450 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89BE2398 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C53468 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C37E18 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C374C0 ^M-- VIOSerialFreeBuffer buf = 89C374C0, buf-va_buf = 89983000 ^MVIOSerialRenewAllPorts ^M-- VIOSerialFillQueue ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C374C0 ^M--
Re: [Qemu-devel] balloon driver on winxp guest start failed
On 10/17/2011 08:55 PM, Vadim Rozenfeld wrote: On Fri, 2011-10-14 at 17:49 +0800, hkran wrote: On 10/14/2011 04:55 AM, Vadim Rozenfeld wrote: On Thu, 2011-10-13 at 15:47 +0100, Stefan Hajnoczi wrote: On Thu, Oct 13, 2011 at 5:00 AM, hkranhk...@vnet.linux.ibm.com wrote: On 10/12/2011 07:09 PM, hkran wrote: I used balloon driver for windows virtio-win-0.1-15.iso (from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/) following the install guard , I installed the balloon driver like this: devcon.exe install d:\wxp\x86\balloon.inf PCI\VEN_1AF4DEV_1002SUBSYS_00051AF4REV_00 then reboot guest Os, but the status of driver installed is always incorrect, that show me the driver start failed (code 10) in the device manager. Seems like a resource allocation problem I typed the following cmds in the monitor command line: (qemu) device_add virtio-balloon (qemu) info balloon balloon: actual=2048 (qemu) balloon 1024 (qemu) info balloon balloon: actual=2048 (qemu) info balloon balloon: actual=2048 And I also tried it by using qemu -balloon virtio param when getting qemu up, the status is worse, the winxp guest froze at boot screen. Am I using balloon driver in a correct way? For the boot failure case, I take more looks into it. I open the trace output and see the following when boot failed Balloon driver, built on Oct 13 2011 10:46:59 ^M-- DriverEntry ^Mfile z:\source\kvm-guest-drivers-windows\balloon\sys\driver.c line 151 ^M-- BalloonDeviceAdd ^M-- BalloonDeviceAdd ^M-- BalloonEvtDevicePrepareHardware ^M- Port Resource [C0A0-C0C0] ^M-- BalloonEvtDevicePrepareHardware ^M-- BalloonEvtDeviceD0Entry ^M-- BalloonInit ^M-- VIRTIO_BALLOON_F_STATS_VQ ^M-- BalloonInit ^M-- BalloonInterruptEnable ^M-- BalloonInterruptEnable here, the system is blocked. I compare it with the logfile in the normal case that I hot-plugin the balloon device, and then find the system blocked before calling at BalloonInterruptDpc. What about ISR? Can you try changing balloon size and check if balloon ISR was invoked or not? Is it meaning that we open the interrupt of balloon device too soon when booting the system? I suggest CCing Vadim on virtio Windows driver questions. Not sure if he sees every qemu-devel email. Stefan To make the issue clearer, I do more tests about that. Now I use the package virtio-win-prewhql-0.1-15-sources.zip from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/ The problem that the balloon driver status is incorrect was not reproduced any longer, but boot failure still be there. more tests told me as if the failure will occur only in the case where virtio-serial and balloon are all attached when qemu booting: (qemu) [huikai@oc0100708617 ~]$ /home/huikai/qemu15/bin/qemu-system-x86_64 --enable-kvm -m 2048 -drive file=/home/huikai/xp_shanghai.img,if=virtio -net user -net nic,model=viga qxl -localtime -chardev stdio,id=muxstdio -mon chardev=muxstdio -usb -usbdevice tablet -device virtio-serial,id=vs0 -chardev socket,path=/tmp/foo,server,nowait,id=foo -device virtserialport,bus=vs0.0,chardev=foo,name=helloworld -serial file:/tmp/xp_1014_6.log -balloon virtio,id=ball1 the trace: Virtio-Serial driver started...built on Oct 14 2011 15:58:02 ^M-- VIOSerialEvtDeviceAdd ^M-- VIOSerialInitInterruptHandling ^MBalloon driver, built on Oct 13 2011 17:34:56 ^M-- DriverEntry ^M-- BalloonDeviceAdd ^M-- BalloonDeviceAdd ^M-- BalloonEvtDevicePrepareHardware ^M- Port Resource [C0A0-C0C0] ^M-- BalloonEvtDevicePrepareHardware ^M-- BalloonEvtDeviceD0Entry ^M-- BalloonInit ^M-- VIRTIO_BALLOON_F_STATS_VQ ^M-- BalloonInit ^M-- BalloonInterruptEnable ^M-- BalloonInterruptEnable ^M-- VIOSerialEvtDevicePrepareHardware ^MIO Port Info [C080-C0A0] ^MWe have multiport host ^MVirtIOConsoleConfig-max_nr_ports 31 ^M-- VIOSerialEvtDeviceD0Entry ^M-- VIOSerialInitAllQueues ^M-- VIOSerialFillQueue ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89B13A50 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89B13638 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C07E08 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C07C50 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C07A98 ... ... ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89BD14B8 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89B826E8 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89BE4450 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89BE2398 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C53468 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C37E18 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C374C0 ^M-- VIOSerialFreeBuffer buf = 89C374C0, buf-va_buf = 89983000 ^MVIOSerialRenewAllPorts ^M-- VIOSerialFillQueue ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C374C0 ^M--
Re: [Qemu-devel] balloon driver on winxp guest start failed
On Fri, 2011-10-14 at 17:49 +0800, hkran wrote: On 10/14/2011 04:55 AM, Vadim Rozenfeld wrote: On Thu, 2011-10-13 at 15:47 +0100, Stefan Hajnoczi wrote: On Thu, Oct 13, 2011 at 5:00 AM, hkranhk...@vnet.linux.ibm.com wrote: On 10/12/2011 07:09 PM, hkran wrote: I used balloon driver for windows virtio-win-0.1-15.iso (from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/) following the install guard , I installed the balloon driver like this: devcon.exe install d:\wxp\x86\balloon.inf PCI\VEN_1AF4DEV_1002SUBSYS_00051AF4REV_00 then reboot guest Os, but the status of driver installed is always incorrect, that show me the driver start failed (code 10) in the device manager. Seems like a resource allocation problem I typed the following cmds in the monitor command line: (qemu) device_add virtio-balloon (qemu) info balloon balloon: actual=2048 (qemu) balloon 1024 (qemu) info balloon balloon: actual=2048 (qemu) info balloon balloon: actual=2048 And I also tried it by using qemu -balloon virtio param when getting qemu up, the status is worse, the winxp guest froze at boot screen. Am I using balloon driver in a correct way? For the boot failure case, I take more looks into it. I open the trace output and see the following when boot failed Balloon driver, built on Oct 13 2011 10:46:59 ^M-- DriverEntry ^Mfile z:\source\kvm-guest-drivers-windows\balloon\sys\driver.c line 151 ^M-- BalloonDeviceAdd ^M-- BalloonDeviceAdd ^M-- BalloonEvtDevicePrepareHardware ^M- Port Resource [C0A0-C0C0] ^M-- BalloonEvtDevicePrepareHardware ^M-- BalloonEvtDeviceD0Entry ^M-- BalloonInit ^M-- VIRTIO_BALLOON_F_STATS_VQ ^M-- BalloonInit ^M-- BalloonInterruptEnable ^M-- BalloonInterruptEnable here, the system is blocked. I compare it with the logfile in the normal case that I hot-plugin the balloon device, and then find the system blocked before calling at BalloonInterruptDpc. What about ISR? Can you try changing balloon size and check if balloon ISR was invoked or not? Is it meaning that we open the interrupt of balloon device too soon when booting the system? I suggest CCing Vadim on virtio Windows driver questions. Not sure if he sees every qemu-devel email. Stefan To make the issue clearer, I do more tests about that. Now I use the package virtio-win-prewhql-0.1-15-sources.zip from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/ The problem that the balloon driver status is incorrect was not reproduced any longer, but boot failure still be there. more tests told me as if the failure will occur only in the case where virtio-serial and balloon are all attached when qemu booting: (qemu) [huikai@oc0100708617 ~]$ /home/huikai/qemu15/bin/qemu-system-x86_64 --enable-kvm -m 2048 -drive file=/home/huikai/xp_shanghai.img,if=virtio -net user -net nic,model=viga qxl -localtime -chardev stdio,id=muxstdio -mon chardev=muxstdio -usb -usbdevice tablet -device virtio-serial,id=vs0 -chardev socket,path=/tmp/foo,server,nowait,id=foo -device virtserialport,bus=vs0.0,chardev=foo,name=helloworld -serial file:/tmp/xp_1014_6.log -balloon virtio,id=ball1 the trace: Virtio-Serial driver started...built on Oct 14 2011 15:58:02 ^M-- VIOSerialEvtDeviceAdd ^M-- VIOSerialInitInterruptHandling ^MBalloon driver, built on Oct 13 2011 17:34:56 ^M-- DriverEntry ^M-- BalloonDeviceAdd ^M-- BalloonDeviceAdd ^M-- BalloonEvtDevicePrepareHardware ^M- Port Resource [C0A0-C0C0] ^M-- BalloonEvtDevicePrepareHardware ^M-- BalloonEvtDeviceD0Entry ^M-- BalloonInit ^M-- VIRTIO_BALLOON_F_STATS_VQ ^M-- BalloonInit ^M-- BalloonInterruptEnable ^M-- BalloonInterruptEnable ^M-- VIOSerialEvtDevicePrepareHardware ^MIO Port Info [C080-C0A0] ^MWe have multiport host ^MVirtIOConsoleConfig-max_nr_ports 31 ^M-- VIOSerialEvtDeviceD0Entry ^M-- VIOSerialInitAllQueues ^M-- VIOSerialFillQueue ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89B13A50 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89B13638 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C07E08 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C07C50 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C07A98 ... ... ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89BD14B8 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89B826E8 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89BE4450 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89BE2398 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C53468 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C37E18 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C374C0 ^M-- VIOSerialFreeBuffer buf = 89C374C0, buf-va_buf = 89983000 ^MVIOSerialRenewAllPorts ^M-- VIOSerialFillQueue
Re: [Qemu-devel] balloon driver on winxp guest start failed
On 10/14/2011 04:55 AM, Vadim Rozenfeld wrote: On Thu, 2011-10-13 at 15:47 +0100, Stefan Hajnoczi wrote: On Thu, Oct 13, 2011 at 5:00 AM, hkranhk...@vnet.linux.ibm.com wrote: On 10/12/2011 07:09 PM, hkran wrote: I used balloon driver for windows virtio-win-0.1-15.iso (from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/) following the install guard , I installed the balloon driver like this: devcon.exe install d:\wxp\x86\balloon.inf PCI\VEN_1AF4DEV_1002SUBSYS_00051AF4REV_00 then reboot guest Os, but the status of driver installed is always incorrect, that show me the driver start failed (code 10) in the device manager. Seems like a resource allocation problem I typed the following cmds in the monitor command line: (qemu) device_add virtio-balloon (qemu) info balloon balloon: actual=2048 (qemu) balloon 1024 (qemu) info balloon balloon: actual=2048 (qemu) info balloon balloon: actual=2048 And I also tried it by using qemu -balloon virtio param when getting qemu up, the status is worse, the winxp guest froze at boot screen. Am I using balloon driver in a correct way? For the boot failure case, I take more looks into it. I open the trace output and see the following when boot failed Balloon driver, built on Oct 13 2011 10:46:59 ^M-- DriverEntry ^Mfile z:\source\kvm-guest-drivers-windows\balloon\sys\driver.c line 151 ^M-- BalloonDeviceAdd ^M-- BalloonDeviceAdd ^M-- BalloonEvtDevicePrepareHardware ^M- Port Resource [C0A0-C0C0] ^M-- BalloonEvtDevicePrepareHardware ^M-- BalloonEvtDeviceD0Entry ^M-- BalloonInit ^M-- VIRTIO_BALLOON_F_STATS_VQ ^M-- BalloonInit ^M-- BalloonInterruptEnable ^M-- BalloonInterruptEnable here, the system is blocked. I compare it with the logfile in the normal case that I hot-plugin the balloon device, and then find the system blocked before calling at BalloonInterruptDpc. What about ISR? Can you try changing balloon size and check if balloon ISR was invoked or not? Is it meaning that we open the interrupt of balloon device too soon when booting the system? I suggest CCing Vadim on virtio Windows driver questions. Not sure if he sees every qemu-devel email. Stefan To make the issue clearer, I do more tests about that. Now I use the package virtio-win-prewhql-0.1-15-sources.zip from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/src/ The problem that the balloon driver status is incorrect was not reproduced any longer, but boot failure still be there. more tests told me as if the failure will occur only in the case where virtio-serial and balloon are all attached when qemu booting: (qemu) [huikai@oc0100708617 ~]$ /home/huikai/qemu15/bin/qemu-system-x86_64 --enable-kvm -m 2048 -drive file=/home/huikai/xp_shanghai.img,if=virtio -net user -net nic,model=viga qxl -localtime -chardev stdio,id=muxstdio -mon chardev=muxstdio -usb -usbdevice tablet -device virtio-serial,id=vs0 -chardev socket,path=/tmp/foo,server,nowait,id=foo -device virtserialport,bus=vs0.0,chardev=foo,name=helloworld -serial file:/tmp/xp_1014_6.log -balloon virtio,id=ball1 the trace: Virtio-Serial driver started...built on Oct 14 2011 15:58:02 ^M-- VIOSerialEvtDeviceAdd ^M-- VIOSerialInitInterruptHandling ^MBalloon driver, built on Oct 13 2011 17:34:56 ^M-- DriverEntry ^M-- BalloonDeviceAdd ^M-- BalloonDeviceAdd ^M-- BalloonEvtDevicePrepareHardware ^M- Port Resource [C0A0-C0C0] ^M-- BalloonEvtDevicePrepareHardware ^M-- BalloonEvtDeviceD0Entry ^M-- BalloonInit ^M-- VIRTIO_BALLOON_F_STATS_VQ ^M-- BalloonInit ^M-- BalloonInterruptEnable ^M-- BalloonInterruptEnable ^M-- VIOSerialEvtDevicePrepareHardware ^MIO Port Info [C080-C0A0] ^MWe have multiport host ^MVirtIOConsoleConfig-max_nr_ports 31 ^M-- VIOSerialEvtDeviceD0Entry ^M-- VIOSerialInitAllQueues ^M-- VIOSerialFillQueue ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89B13A50 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89B13638 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C07E08 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C07C50 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C07A98 ... ... ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89BD14B8 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89B826E8 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89BE4450 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89BE2398 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C53468 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C37E18 ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C374C0 ^M-- VIOSerialFreeBuffer buf = 89C374C0, buf-va_buf = 89983000 ^MVIOSerialRenewAllPorts ^M-- VIOSerialFillQueue ^M-- VIOSerialAllocateBuffer ^M-- VIOSerialAddInBuf buf = 89C374C0 ^M-- VIOSerialFreeBuffer buf = 89C374C0, buf-va_buf = 89983000 ^MSetting VIRTIO_CONFIG_S_DRIVER_OK flag ^M not any more output here.
Re: [Qemu-devel] balloon driver on winxp guest start failed
On Thu, Oct 13, 2011 at 5:00 AM, hkran hk...@vnet.linux.ibm.com wrote: On 10/12/2011 07:09 PM, hkran wrote: I used balloon driver for windows virtio-win-0.1-15.iso (from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/) following the install guard , I installed the balloon driver like this: devcon.exe install d:\wxp\x86\balloon.inf PCI\VEN_1AF4DEV_1002SUBSYS_00051AF4REV_00 then reboot guest Os, but the status of driver installed is always incorrect, that show me the driver start failed (code 10) in the device manager. I typed the following cmds in the monitor command line: (qemu) device_add virtio-balloon (qemu) info balloon balloon: actual=2048 (qemu) balloon 1024 (qemu) info balloon balloon: actual=2048 (qemu) info balloon balloon: actual=2048 And I also tried it by using qemu -balloon virtio param when getting qemu up, the status is worse, the winxp guest froze at boot screen. Am I using balloon driver in a correct way? For the boot failure case, I take more looks into it. I open the trace output and see the following when boot failed Balloon driver, built on Oct 13 2011 10:46:59 ^M-- DriverEntry ^Mfile z:\source\kvm-guest-drivers-windows\balloon\sys\driver.c line 151 ^M-- BalloonDeviceAdd ^M-- BalloonDeviceAdd ^M-- BalloonEvtDevicePrepareHardware ^M- Port Resource [C0A0-C0C0] ^M-- BalloonEvtDevicePrepareHardware ^M-- BalloonEvtDeviceD0Entry ^M-- BalloonInit ^M-- VIRTIO_BALLOON_F_STATS_VQ ^M-- BalloonInit ^M-- BalloonInterruptEnable ^M-- BalloonInterruptEnable here, the system is blocked. I compare it with the logfile in the normal case that I hot-plugin the balloon device, and then find the system blocked before calling at BalloonInterruptDpc. Is it meaning that we open the interrupt of balloon device too soon when booting the system? I suggest CCing Vadim on virtio Windows driver questions. Not sure if he sees every qemu-devel email. Stefan
Re: [Qemu-devel] balloon driver on winxp guest start failed
On Thu, 2011-10-13 at 15:47 +0100, Stefan Hajnoczi wrote: On Thu, Oct 13, 2011 at 5:00 AM, hkran hk...@vnet.linux.ibm.com wrote: On 10/12/2011 07:09 PM, hkran wrote: I used balloon driver for windows virtio-win-0.1-15.iso (from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/) following the install guard , I installed the balloon driver like this: devcon.exe install d:\wxp\x86\balloon.inf PCI\VEN_1AF4DEV_1002SUBSYS_00051AF4REV_00 then reboot guest Os, but the status of driver installed is always incorrect, that show me the driver start failed (code 10) in the device manager. Seems like a resource allocation problem I typed the following cmds in the monitor command line: (qemu) device_add virtio-balloon (qemu) info balloon balloon: actual=2048 (qemu) balloon 1024 (qemu) info balloon balloon: actual=2048 (qemu) info balloon balloon: actual=2048 And I also tried it by using qemu -balloon virtio param when getting qemu up, the status is worse, the winxp guest froze at boot screen. Am I using balloon driver in a correct way? For the boot failure case, I take more looks into it. I open the trace output and see the following when boot failed Balloon driver, built on Oct 13 2011 10:46:59 ^M-- DriverEntry ^Mfile z:\source\kvm-guest-drivers-windows\balloon\sys\driver.c line 151 ^M-- BalloonDeviceAdd ^M-- BalloonDeviceAdd ^M-- BalloonEvtDevicePrepareHardware ^M- Port Resource [C0A0-C0C0] ^M-- BalloonEvtDevicePrepareHardware ^M-- BalloonEvtDeviceD0Entry ^M-- BalloonInit ^M-- VIRTIO_BALLOON_F_STATS_VQ ^M-- BalloonInit ^M-- BalloonInterruptEnable ^M-- BalloonInterruptEnable here, the system is blocked. I compare it with the logfile in the normal case that I hot-plugin the balloon device, and then find the system blocked before calling at BalloonInterruptDpc. What about ISR? Can you try changing balloon size and check if balloon ISR was invoked or not? Is it meaning that we open the interrupt of balloon device too soon when booting the system? I suggest CCing Vadim on virtio Windows driver questions. Not sure if he sees every qemu-devel email. Stefan
[Qemu-devel] balloon driver on winxp guest start failed
Hi, I used balloon driver for windows virtio-win-0.1-15.iso (from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/) following the install guard , I installed the balloon driver like this: devcon.exe install d:\wxp\x86\balloon.inf PCI\VEN_1AF4DEV_1002SUBSYS_00051AF4REV_00 then reboot guest Os, but the status of driver installed is always incorrect, that show me the driver start failed (code 10) in the device manager. I typed the following cmds in the monitor command line: (qemu) device_add virtio-balloon (qemu) info balloon balloon: actual=2048 (qemu) balloon 1024 (qemu) info balloon balloon: actual=2048 (qemu) info balloon balloon: actual=2048 And I also tried it by using qemu -balloon virtio param when getting qemu up, the status is worse, the winxp guest froze at boot screen. Am I using balloon driver in a correct way?
Re: [Qemu-devel] balloon driver on winxp guest start failed
On 10/12/2011 07:09 PM, hkran wrote: Hi, I used balloon driver for windows virtio-win-0.1-15.iso (from http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/) following the install guard , I installed the balloon driver like this: devcon.exe install d:\wxp\x86\balloon.inf PCI\VEN_1AF4DEV_1002SUBSYS_00051AF4REV_00 then reboot guest Os, but the status of driver installed is always incorrect, that show me the driver start failed (code 10) in the device manager. I typed the following cmds in the monitor command line: (qemu) device_add virtio-balloon (qemu) info balloon balloon: actual=2048 (qemu) balloon 1024 (qemu) info balloon balloon: actual=2048 (qemu) info balloon balloon: actual=2048 And I also tried it by using qemu -balloon virtio param when getting qemu up, the status is worse, the winxp guest froze at boot screen. Am I using balloon driver in a correct way? For the boot failure case, I take more looks into it. I open the trace output and see the following when boot failed Balloon driver, built on Oct 13 2011 10:46:59 ^M-- DriverEntry ^Mfile z:\source\kvm-guest-drivers-windows\balloon\sys\driver.c line 151 ^M-- BalloonDeviceAdd ^M-- BalloonDeviceAdd ^M-- BalloonEvtDevicePrepareHardware ^M- Port Resource [C0A0-C0C0] ^M-- BalloonEvtDevicePrepareHardware ^M-- BalloonEvtDeviceD0Entry ^M-- BalloonInit ^M-- VIRTIO_BALLOON_F_STATS_VQ ^M-- BalloonInit ^M-- BalloonInterruptEnable ^M-- BalloonInterruptEnable here, the system is blocked. I compare it with the logfile in the normal case that I hot-plugin the balloon device, and then find the system blocked before calling at BalloonInterruptDpc. Is it meaning that we open the interrupt of balloon device too soon when booting the system?
Re: [Qemu-devel] balloon driver
Worse, the guest might decide to swap out a page that's already swapped in by the host, forcing it to be read in again only to be immediately written out to disk by the guest :-( ...unless the guest's disk I/O is with simulated DMA or recognisable block-copy instruction sequences, and doesn't look at the data. In that case the emulator can, in principle, keep track of where pages are copied around without being examined, and avoid actually swapping them in. Probably not worth the complexity. Another solution, taken by the Disco VMM was to provide a special virtual disk device for the swap device which fakes out swapping behaviour - accesses to that device are always going to be swaps, so you can guarantee to do the right thing without having to trace and interpret behaviour. That said, I like your idea of not committing IOs for DMA-ed pages than have not been inspected, but one would have to be careful to make sure that true page-size DMA writes of data do still hit the disk in a timely fashion. Cheers, Mark -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] balloon driver
On 7/5/06, Paul Brook [EMAIL PROTECTED] wrote: On Wednesday 05 July 2006 03:58, Eric L wrote: I've been playing around with QEMU the past few days and have been quite impressed. One thing I wondered about: it seems that most of the other virtualization schemes have some sort of balloon driver to reclaim unused (cached) guest memory. (VMWare, Xen and I think user mode linux has something too). It seems like a pretty good idea to me, but from my searching, it would appear that QEMU does not have anything similar. Is this correct? If so, is there a reason why? Partly because qemu is just a normal user application. It can be swapped out by the host OS just like any other process. Adding a few Gb of extra swap and letting the host OS figure it out should get you 90% of the benefit. Paul It seems the point of the balloon driver is to avoid forcing the host to swap. For example, suppose I start a new guest OS. I check the memory usage on the host and everything looks pretty good, maybe 30MB used. Then suppose I run a recursive grep command in a Linux source tree on the guest. The host memory usage will climb to the maximum allotted memory as the guest OS fills its page cache with pages of kernel source. Now, I go back to the host and decide I want to run something a little memory intensive. The host has to swap and dutifully copies those pages of kernel source to swap. Much better would be if I could just chuck those pages and give them back to the host, no swapping at all. Even if the guest has to swap, the reasoning is that the guest is in a much better position to figure out what to swap than if the host were forced to. It is a rather crude approach and I'm not sure how much practical benefit there is, but I'll probably go ahead and code it up (at least for a Linux host) if only for myself as it looks pretty simple. (Linux 2.6.16 added the ability to punch holes in tmpfs files so all the hard work should be done). I just wondered if there was anything I was missing or if anyone had considered it before. - E ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] balloon driver
It seems the point of the balloon driver is to avoid forcing the host to swap. For example, suppose I start a new guest OS. I check the memory usage on the host and everything looks pretty good, maybe 30MB used. Then suppose I run a recursive grep command in a Linux source tree on the guest. The host memory usage will climb to the maximum allotted memory as the guest OS fills its page cache with pages of kernel source. Now, I go back to the host and decide I want to run something a little memory intensive. The host has to swap and dutifully copies those pages of kernel source to swap. Much better would be if I could just chuck those pages and give them back to the host, no swapping at all. Even if the guest has to swap, the reasoning is that the guest is in a much better position to figure out what to swap than if the host were forced to. Worse, the guest might decide to swap out a page that's already swapped in by the host, forcing it to be read in again only to be immediately written out to disk by the guest :-( It is a rather crude approach and I'm not sure how much practical benefit there is, but I'll probably go ahead and code it up (at least for a Linux host) if only for myself as it looks pretty simple. (Linux 2.6.16 added the ability to punch holes in tmpfs files so all the hard work should be done). I just wondered if there was anything I was missing or if anyone had considered it before. Xen has a balloon driver - you might like to take a look at that for starters, and maybe borrow some code from it! There's been occasional talk to the effect that a number of projects might as well share functionality like ballooning since a number of systems require it. Cheers, Mark - E ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Dave: Just a question. What use is a unicyle with no seat? And no pedals! Mark: To answer a question with a question: What use is a skateboard? Dave: Skateboards have wheels. Mark: My wheel has a wheel! ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] balloon driver
Mark Williamson wrote: Even if the guest has to swap, the reasoning is that the guest is in a much better position to figure out what to swap than if the host were forced to. Worse, the guest might decide to swap out a page that's already swapped in by the host, forcing it to be read in again only to be immediately written out to disk by the guest :-( ...unless the guest's disk I/O is with simulated DMA or recognisable block-copy instruction sequences, and doesn't look at the data. In that case the emulator can, in principle, keep track of where pages are copied around without being examined, and avoid actually swapping them in. Probably not worth the complexity. -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] balloon driver
On Wednesday 05 July 2006 03:58, Eric L wrote: I've been playing around with QEMU the past few days and have been quite impressed. One thing I wondered about: it seems that most of the other virtualization schemes have some sort of balloon driver to reclaim unused (cached) guest memory. (VMWare, Xen and I think user mode linux has something too). It seems like a pretty good idea to me, but from my searching, it would appear that QEMU does not have anything similar. Is this correct? If so, is there a reason why? Partly because qemu is just a normal user application. It can be swapped out by the host OS just like any other process. Adding a few Gb of extra swap and letting the host OS figure it out should get you 90% of the benefit. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
