Re: [Qemu-devel] balloon driver on winxp guest start failed

[hkran <hkran@vnet.linux.ibm.com>]

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<hkran@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_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