From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJMcc-00037O-0y for qemu-devel@nongnu.org; Thu, 27 Oct 2011 05:51:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RJMca-0002IN-DC for qemu-devel@nongnu.org; Thu, 27 Oct 2011 05:51:37 -0400 Received: from e28smtp09.in.ibm.com ([122.248.162.9]:58327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJMcZ-0002ID-B2 for qemu-devel@nongnu.org; Thu, 27 Oct 2011 05:51:36 -0400 Received: from /spool/local by e28smtp09.in.ibm.com with XMail ESMTP for from ; Thu, 27 Oct 2011 15:21:31 +0530 Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay05.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p9R9oAms2474184 for ; Thu, 27 Oct 2011 15:20:10 +0530 Received: from d28av05.in.ibm.com (loopback [127.0.0.1]) by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p9R9oAOu018313 for ; Thu, 27 Oct 2011 20:50:10 +1100 Message-ID: <4EA9291E.4010504@vnet.linux.ibm.com> Date: Thu, 27 Oct 2011 17:49:18 +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> <4E9805BE.1080000@vnet.linux.ibm.com> <1318856142.2803.24.camel@vadimr.dell> In-Reply-To: <1318856142.2803.24.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/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, 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. >> > What does "info pci" say? > Best, > Vadim. >> > > when hotplugin the virtio-serial, hanggning is easy to happen. when windows hung, captched the callstack by using windbg tool here. not sure if it helps. kd> k ChildEBP RetAddr f315194c 80542155 nt!RtlpBreakWithStatusInstruction f315194c 806d42a8 nt!KeUpdateSystemTime+0x165 f31519d0 80546451 hal!KeRaiseIrqlToDpcLevel+0x10 f3151a2c 8056bab8 nt!ExAllocatePoolWithTag+0x4d1 f3151a50 f576bfbf nt!IoConnectInterrupt+0x48 f3151ac4 f5768f55 wdf01000!FxInterrupt::Connect+0x11d f3151ae4 f5765fc7 wdf01000!FxPkgPnp::NotifyResourceObjectsD0+0x27 f3151af4 f5765d81 wdf01000!FxPkgPnp::PowerD0StartingConnectInterrupt+0x12 f3151b7c f5766bb2 wdf01000!FxPkgPnp::PowerEnterNewState+0x11c f3151ba0 f57675bb wdf01000!FxPkgPnp::PowerProcessEventInner+0x171 f3151bc4 f576c8b4 wdf01000!FxPkgPnp::PowerProcessEvent+0x15c f3151bd4 f576c832 wdf01000!FxPkgPnp::PowerPolStarting+0x1d f3151c5c f576d716 wdf01000!FxPkgPnp::PowerPolicyEnterNewState+0x11c f3151c80 f576e388 wdf01000!FxPkgPnp::PowerPolicyProcessEventInner+0x185 f3151ca4 f576b5a8 wdf01000!FxPkgPnp::PowerPolicyProcessEvent+0x172 f3151cc0 f576a484 wdf01000!FxPkgPnp::PnpEventHardwareAvailable+0x90 f3151ce8 f576adb2 wdf01000!FxPkgPnp::PnpEnterNewState+0x104 f3151d0c f576b503 wdf01000!FxPkgPnp::PnpProcessEventInner+0x149 f3151d20 f576ed1c wdf01000!FxPkgPnp::_PnpProcessEventInner+0x26 f3151d50 f576fff8 wdf01000!FxEventQueue::EventQueueWorker+0x6f f3151d60 8056cdd5 wdf01000!FxWorkItemEventQueue::_WorkItemCallback+0x21 f3151d74 80535ca0 nt!IopProcessWorkItem+0x13 f3151dac 805c72c2 nt!ExpWorkerThread+0x100 f3151ddc 80542e82 nt!PspSystemThreadStartup+0x34 00000000 00000000 nt!KiThreadStartup+0x16