From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38712) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RnmtA-0001Sx-98 for qemu-devel@nongnu.org; Thu, 19 Jan 2012 02:58:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rnmt8-000890-5w for qemu-devel@nongnu.org; Thu, 19 Jan 2012 02:58:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59391) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rnmt7-00088l-0R for qemu-devel@nongnu.org; Thu, 19 Jan 2012 02:58:26 -0500 From: Vadim Rozenfeld In-Reply-To: References: <20120101114514.GC20432@garlic.redhat.com> <20120101141928.GE20432@garlic.redhat.com> <20120102101855.GH20432@garlic.redhat.com> <20120102114919.GJ20432@garlic.redhat.com> <1326627698.2734.1.camel@vadimr.dell> <4F14D3D5.9050202@linux.vnet.ibm.com> <1326833810.5467.4.camel@vadimr.dell> Content-Type: text/plain; charset="UTF-8" Date: Thu, 19 Jan 2012 09:58:03 +0200 Message-ID: <1326959883.4768.2.camel@vadimr.dell> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Charles=2ETsai-=E8=94=A1=E6=B8=85=E6=B5=B7-=E7=A0=94=E7=A9=B6?= =?UTF-8?Q?=E7=99=BC=E5=B1=95=E9=83=A8?= Cc: Stefan Hajnoczi , qemu-devel , Michael Roth , Alon Levy , spice-devel@lists.freedesktop.org, Alex =?UTF-8?Q?Huang-=E9=BB=83=E5=BF=85=E8=B3=A2-=E7=A0=94=E7=A9=B6=E7=99=BC?= =?UTF-8?Q?=E5=B1=95=E9=83=A8?= On Thu, 2012-01-19 at 09:41 +0800, Charles.Tsai-=E8=94=A1=E6=B8=85=E6=B5=B7= -=E7=A0=94=E7=A9=B6=E7=99=BC=E5=B1=95=E9=83=A8 wrote: > Vadim, >=20 > 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. >=20 On UP or SMP system? >=20 > -----Original Message----- > From: Vadim Rozenfeld [mailto:vrozenfe@redhat.com]=20 > Sent: Wednesday, January 18, 2012 4:57 AM > To: Michael Roth > Cc: Charles.Tsai-=E8=94=A1=E6=B8=85=E6=B5=B7-=E7=A0=94=E7=A9=B6=E7=99=BC= =E5=B1=95=E9=83=A8; Stefan Hajnoczi; spice-devel@lists.freedesktop.org; A= lex Huang-=E9=BB=83=E5=BF=85=E8=B3=A2-=E7=A0=94=E7=A9=B6=E7=99=BC=E5=B1=95= =E9=83=A8; Alon Levy; qemu-devel > Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS o= n Qemu 0.15 >=20 > On Mon, 2012-01-16 at 19:50 -0600, Michael Roth wrote: > > On 01/15/2012 08:02 PM, Charles.Tsai-=E8=94=A1=E6=B8=85=E6=B5=B7-=E7=A0= =94=E7=A9=B6=E7=99=BC=E5=B1=95=E9=83=A8 wrote: > > > Vadim, > > > > > > Thank you for your prompt reply. Here are the information for our t= est 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=20 > > > 1,sockets=3D1,cores=3D1,threads=3D1 -name win_xp -uuid=20 > > > d9388815-ddd3-c38e-33c2-a9d5fcc7a775 -nodefconfig -nodefaults=20 > > > -chardev=20 > > > socket,id=3Dcharmonitor,path=3D/var/lib/libvirt/qemu/win_xp.monitor= ,serv > > > er,nowait -mon chardev=3Dcharmonitor,id=3Dmonitor,mode=3Dreadline > > > -rtc base=3Dlocaltime > > > -device=20 > > > virtio-serial-pci,id=3Dvirtio-serial0,bus=3Dpci.0,multifunction=3Do= n,addr=3D > > > 0x5.0x0 -drive=20 > > > file=3D/media/Images/Windows-XP.img,if=3Dnone,id=3Ddrive-ide0-0-0,f= ormat=3Dr > > > aw -device=20 > > > ide-drive,bus=3Dide.0,unit=3D0,drive=3Ddrive-ide0-0-0,id=3Dide0-0-0= ,bootinde > > > x=3D1 > > > -netdev tap,fd=3D17,id=3Dhostnet0 > > > -device=20 > > > rtl8139,netdev=3Dhostnet0,id=3Dnet0,mac=3D52:54:00:e8:dc:b1,bus=3Dp= ci.0,mult > > > ifunction=3Don,addr=3D0x3.0x0 > > > -chardev pty,id=3Dcharserial0 > > > -device isa-serial,chardev=3Dcharserial0,id=3Dserial0 > > > -chardev spicevmc,id=3Dcharchannel0,name=3Dvdagent > > > -device=20 > > > virtserialport,bus=3Dvirtio-serial0.0,nr=3D1,chardev=3Dcharchannel0= ,id=3Dcha > > > nnel0,name=3Dcom.redhat.spice.0 > > > -usb -device usb-tablet,id=3Dinput0 > > > -spice port=3D5900,addr=3D0.0.0.0,disable-ticketing > > > -vga qxl -global qxl-vga.vram_size=3D67108864 -device=20 > > > virtio-balloon-pci,id=3Dballoon0,bus=3Dpci.0,multifunction=3Don,add= r=3D0x4.0 > > > x0 > > > > > > > > > > > > 2). In Guest Windows XP OS > > > > > > > > > When the following callback function of the vioserial device is ca= lled 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 l= ogical address space. > > > > > > I added the following trace and the value of nListSize is ZERO. > > > TraceEvents(TRACE_LEVEL_INFORMATION, DBG_PNP, "%s (nListSize=3D%d)\= n",=20 > > > __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. > > > > >=20 > > Hi Charles, > >=20 > > What versions of the virtio-win drivers are you using? > >=20 > > I've been testing virtio-serial on windows using the latest qemu.git=20 > > (1.0). Linux guests work fine, but I've been having various issues=20 > > with Windows 7, XP SP3, and Server 2008 R1. XP SP3 works=20 > > intermittently for me using RHEL6.0 virtio-win, as well as the driver= s at: > >=20 >=20 > 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). >=20 > > http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/ > >=20 > > But I've been getting a mix of issues such as guest hangs, vioser-tes= t=20 > > failing to enumerate any virtio-serial devices, or various=20 > > non-critical error messages from qemu that seem to coincide with the=20 > > channel being open/closed (occasionally resulting in the channel beco= ming unresponsive). > >=20 > > Do any of these seem similar to the behaviour you're seeing? If so=20 > > I'll see if the issues go away on 0.14.0 and follow-up with a git bis= ect. > >=20 >=20 >=20 >=20