Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15

[Vadim Rozenfeld]

On Thu, 2012-01-19 at 09:41 +0800, Charles.Tsai-蔡清海-研究發展部 wrote:
> Vadim,
> 
> I tested on Qemu 1.0.50. and found the VioSerial driver had problem to 
> install on 64-bit Win7 guest.
> During the driver installation, the system hung after the driver being 
> installed. After I rebooted the
> guest OS, the Vioserial driver work. The hang system seemed to be found only 
> during the driver installation.
> 
On UP or SMP system?
> 
> -----Original Message-----
> From: Vadim Rozenfeld [mailto:address@hidden 
> Sent: Wednesday, January 18, 2012 4:57 AM
> To: Michael Roth
> Cc: Charles.Tsai-蔡清海-研究發展部; Stefan Hajnoczi; address@hidden; Alex 
> Huang-黃必賢-研究發展部; Alon Levy; qemu-devel
> Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 
> 0.15
> 
> On Mon, 2012-01-16 at 19:50 -0600, Michael Roth wrote:
> > On 01/15/2012 08:02 PM, Charles.Tsai-蔡清海-研究發展部 wrote:
> > > Vadim,
> > >
> > > Thank you for your prompt reply. Here are the information for our test 
> > > case.
> > >
> > >
> > > 1) we use the following command line to launch the guest OS
> > >
> > >
> > > /usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 1024 -smp 
> > > 1,sockets=1,cores=1,threads=1 -name win_xp -uuid 
> > > d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults 
> > > -chardev 
> > > socket,id=charmonitor,path=/var/lib/libvirt/qemu/win_xp.monitor,serv
> > > er,nowait -mon chardev=charmonitor,id=monitor,mode=readline
> > > -rtc base=localtime
> > > -device 
> > > virtio-serial-pci,id=virtio-serial0,bus=pci.0,multifunction=on,addr=
> > > 0x5.0x0 -drive 
> > > file=/media/Images/Windows-XP.img,if=none,id=drive-ide0-0-0,format=r
> > > aw -device 
> > > ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootinde
> > > x=1
> > > -netdev tap,fd=17,id=hostnet0
> > > -device 
> > > rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:e8:dc:b1,bus=pci.0,mult
> > > ifunction=on,addr=0x3.0x0
> > > -chardev pty,id=charserial0
> > > -device isa-serial,chardev=charserial0,id=serial0
> > > -chardev spicevmc,id=charchannel0,name=vdagent
> > > -device 
> > > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=cha
> > > nnel0,name=com.redhat.spice.0
> > > -usb -device usb-tablet,id=input0
> > > -spice port=5900,addr=0.0.0.0,disable-ticketing
> > > -vga qxl -global qxl-vga.vram_size=67108864 -device 
> > > virtio-balloon-pci,id=balloon0,bus=pci.0,multifunction=on,addr=0x4.0
> > > x0
> > >
> > >
> > >
> > > 2). In Guest Windows XP OS
> > >
> > >
> > > When the following callback function of the vioserial device  is called 
> > > in guest OS. The allocated resources is empty.
> > >
> > >
> > > VIOSerialEvtDevicePrepareHardware() ---This function is to get the I/O 
> > > address of the vioserial device and map the physical address to the 
> > > logical address space.
> > >
> > > I added the following trace and the value of nListSize is ZERO.
> > > TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=%d)\n", 
> > > __FUNCTION__,nListSize);
> > >
> > >
> > > So far, we have tested Qemu 0.14 without any problem but Qemu 0.15 seemed 
> > > to be broken in vioserial device.
> > > Let me know if you need further information. Thanks.
> > >
> > 
> > Hi Charles,
> > 
> > What versions of the virtio-win drivers are you using?
> > 
> > I've been testing virtio-serial on windows using the latest qemu.git 
> > (1.0). Linux guests work fine, but I've been having various issues 
> > with Windows 7, XP SP3, and Server 2008 R1. XP SP3 works 
> > intermittently for me using RHEL6.0 virtio-win, as well as the drivers at:
> > 
> 
> I have seen some virtio serial port initialization problems on 1.0.50.
> Will try to look into this problem in the following week(s).
> 
> > http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/
> > 
> > But I've been getting a mix of issues such as guest hangs, vioser-test 
> > failing to enumerate any virtio-serial devices, or various 
> > non-critical error messages from qemu that seem to coincide with the 
> > channel being open/closed (occasionally resulting in the channel becoming 
> > unresponsive).
> > 
> > Do any of these seem similar to the behaviour you're seeing? If so 
> > I'll see if the issues go away on 0.14.0 and follow-up with a git bisect.
> > 
> 
> 
>