From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37954) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1REePZ-0002N2-JK for qemu-devel@nongnu.org; Fri, 14 Oct 2011 05:50:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1REePX-0007Qo-CA for qemu-devel@nongnu.org; Fri, 14 Oct 2011 05:50:41 -0400 Received: from e28smtp03.in.ibm.com ([122.248.162.3]:37414) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1REePW-0007QA-M0 for qemu-devel@nongnu.org; Fri, 14 Oct 2011 05:50:39 -0400 Received: from d28relay01.in.ibm.com (d28relay01.in.ibm.com [9.184.220.58]) by e28smtp03.in.ibm.com (8.14.4/8.13.1) with ESMTP id p9E9oWaF016878 for ; Fri, 14 Oct 2011 15:20:32 +0530 Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p9E9oWIn2511008 for ; Fri, 14 Oct 2011 15:20:32 +0530 Received: from d28av01.in.ibm.com (loopback [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p9E9oV9t021974 for ; Fri, 14 Oct 2011 15:20:31 +0530 Message-ID: <4E9805BE.1080000@vnet.linux.ibm.com> Date: Fri, 14 Oct 2011 17:49:50 +0800 From: hkran MIME-Version: 1.0 References: <4E957566.3010705@vnet.linux.ibm.com> <4E966259.4020500@vnet.linux.ibm.com> <1318539326.2706.90.camel@vadimr.dell> In-Reply-To: <1318539326.2706.90.camel@vadimr.dell> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] balloon driver on winxp guest start failed List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vadim Rozenfeld Cc: Stefan Hajnoczi , qemu-devel@nongnu.org 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, hkran 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_1AF4&DEV_1002&SUBSYS_00051AF4&REV_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 [0000C0A0-0000C0C0] >>> ^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 [0000C0A0-0000C0C0] ^M<-- BalloonEvtDevicePrepareHardware ^M--> BalloonEvtDeviceD0Entry ^M--> BalloonInit ^M--> VIRTIO_BALLOON_F_STATS_VQ ^M<-- BalloonInit ^M--> BalloonInterruptEnable ^M<-- BalloonInterruptEnable ^M<--> VIOSerialEvtDevicePrepareHardware ^MIO Port Info [0000C080-0000C0A0] ^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.