All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] balloon driver on winxp guest start failed
@ 2011-10-12 11:09 hkran
  2011-10-13  4:00 ` hkran
  0 siblings, 1 reply; 8+ messages in thread
From: hkran @ 2011-10-12 11:09 UTC (permalink / raw)
  To: qemu-devel

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_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.

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?

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [Qemu-devel] balloon driver on winxp guest start failed
  2011-10-12 11:09 [Qemu-devel] balloon driver on winxp guest start failed hkran
@ 2011-10-13  4:00 ` hkran
  2011-10-13 14:47   ` Stefan Hajnoczi
  0 siblings, 1 reply; 8+ messages in thread
From: hkran @ 2011-10-13  4:00 UTC (permalink / raw)
  To: qemu-devel

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_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.
>
> 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.

Is it meaning that we open the interrupt of balloon device too soon when 
booting the system?

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [Qemu-devel] balloon driver on winxp guest start failed
  2011-10-13  4:00 ` hkran
@ 2011-10-13 14:47   ` Stefan Hajnoczi
  2011-10-13 20:55     ` Vadim Rozenfeld
  0 siblings, 1 reply; 8+ messages in thread
From: Stefan Hajnoczi @ 2011-10-13 14:47 UTC (permalink / raw)
  To: hkran; +Cc: qemu-devel, Vadim Rozenfeld

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.
>>
>> 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.
>
> 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

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [Qemu-devel] balloon driver on winxp guest start failed
  2011-10-13 14:47   ` Stefan Hajnoczi
@ 2011-10-13 20:55     ` Vadim Rozenfeld
  2011-10-14  9:49       ` hkran
  0 siblings, 1 reply; 8+ messages in thread
From: Vadim Rozenfeld @ 2011-10-13 20:55 UTC (permalink / raw)
  To: Stefan Hajnoczi; +Cc: hkran, qemu-devel

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

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [Qemu-devel] balloon driver on winxp guest start failed
  2011-10-13 20:55     ` Vadim Rozenfeld
@ 2011-10-14  9:49       ` hkran
  2011-10-17 12:55         ` Vadim Rozenfeld
  0 siblings, 1 reply; 8+ messages in thread
From: hkran @ 2011-10-14  9:49 UTC (permalink / raw)
  To: Vadim Rozenfeld; +Cc: Stefan Hajnoczi, qemu-devel

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [Qemu-devel] balloon driver on winxp guest start failed
  2011-10-14  9:49       ` hkran
@ 2011-10-17 12:55         ` Vadim Rozenfeld
  2011-10-20  7:55           ` hkran
  2011-10-27  9:49           ` hkran
  0 siblings, 2 replies; 8+ messages in thread
From: Vadim Rozenfeld @ 2011-10-17 12:55 UTC (permalink / raw)
  To: hkran; +Cc: Stefan Hajnoczi, qemu-devel

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.
> 
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [Qemu-devel] balloon driver on winxp guest start failed
  2011-10-17 12:55         ` Vadim Rozenfeld
@ 2011-10-20  7:55           ` hkran
  2011-10-27  9:49           ` hkran
  1 sibling, 0 replies; 8+ messages in thread
From: hkran @ 2011-10-20  7:55 UTC (permalink / raw)
  To: Vadim Rozenfeld; +Cc: Stefan Hajnoczi, qemu-devel

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 windows hung, info pci output:
(qemu) info pci
   Bus  0, device   0, function 0:
     Host bridge: PCI device 8086:1237
       id ""
   Bus  0, device   1, function 0:
     ISA bridge: PCI device 8086:7000
       id ""
   Bus  0, device   1, function 1:
     IDE controller: PCI device 8086:7010
       BAR4: I/O at 0xc0c0 [0xc0cf].
       id ""
   Bus  0, device   1, function 2:
     USB controller: PCI device 8086:7020
       IRQ 5.
       BAR4: I/O at 0xc040 [0xc05f].
       id ""
   Bus  0, device   1, function 3:
     Bridge: PCI device 8086:7113
       IRQ 9.
       id ""
   Bus  0, device   2, function 0:
     VGA controller: PCI device 1013:00b8
       BAR0: 32 bit prefetchable memory at 0xfc000000 [0xfdffffff].
       BAR1: 32 bit memory at 0xfebf0000 [0xfebf0fff].
       BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
       id ""
   Bus  0, device   3, function 0:
     Ethernet controller: PCI device 1af4:1000
       IRQ 11.
       BAR0: I/O at 0xc060 [0xc07f].
       BAR1: 32 bit memory at 0xfebf1000 [0xfebf1fff].
       BAR6: 32 bit memory at 0xffffffffffffffff [0x0000fffe].
       id ""
   Bus  0, device   4, function 0:
     Class 1920: PCI device 1af4:1003
       IRQ 5.
       BAR0: I/O at 0xc080 [0xc09f].
       BAR1: 32 bit memory at 0xfebf2000 [0xfebf2fff].
       id "vs0"
   Bus  0, device   5, function 0:
     RAM controller: PCI device 1af4:1002
       IRQ 11.
       BAR0: I/O at 0xc0a0 [0xc0bf].
       id "ball1"
   Bus  0, device   6, function 0:
     SCSI controller: PCI device 1af4:1001
       IRQ 10.
       BAR0: I/O at 0xc000 [0xc03f].
       BAR1: 32 bit memory at 0xfebf3000 [0xfebf3fff].
       id ""
(qemu)

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re: [Qemu-devel] balloon driver on winxp guest start failed
  2011-10-17 12:55         ` Vadim Rozenfeld
  2011-10-20  7:55           ` hkran
@ 2011-10-27  9:49           ` hkran
  1 sibling, 0 replies; 8+ messages in thread
From: hkran @ 2011-10-27  9:49 UTC (permalink / raw)
  To: Vadim Rozenfeld; +Cc: Stefan Hajnoczi, qemu-devel

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

^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-10-27  9:51 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-10-12 11:09 [Qemu-devel] balloon driver on winxp guest start failed hkran
2011-10-13  4:00 ` hkran
2011-10-13 14:47   ` Stefan Hajnoczi
2011-10-13 20:55     ` Vadim Rozenfeld
2011-10-14  9:49       ` hkran
2011-10-17 12:55         ` Vadim Rozenfeld
2011-10-20  7:55           ` hkran
2011-10-27  9:49           ` hkran

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.