qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Charles . Tsai-蔡清海-研究發展部
Subject: Re: [Qemu-devel] [Spice-devel] Vioserial of Windows guest OS on Qemu 0.15
Date: Thu, 19 Jan 2012 09:41:15 +0800

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.


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]