Bug 1166031

According to dgilbert's advice ,move bug to virtio-win component first 

Mike

I was able to reproduce with the serial test python scripts.

However it seems that it works okay if using "nc -U /tmp/vport0" (or "socat unix-connect:/tmp/vport0 -") to connect from the host side and send data to the guest.

(In reply to Gal Hammer from comment #4)
> I was able to reproduce with the serial test python scripts.
> 
> However it seems that it works okay if using "nc -U /tmp/vport0" (or "socat
> unix-connect:/tmp/vport0 -") to connect from the host side and send data to
> the guest.

yes,QE retest via "nc -U /tmp/tt0",guest can receive data successfully. 

steps:
host：
#echo helloguest | nc -U /tmp/tt0

guest:
CLI: #vioser-test.exe
     #r

After further look, it looks like the problem is with the way the scripts works (open a port, write to the port and then close it). It cause either qemu or the guest to drop the messages because it assume that there is no listener on the other side.

Amit? Did something change between qemu 1.5.3 and 2.1.2 which is related to the detection of a connect/disconnect to a char device?

(In reply to Gal Hammer from comment #6)
> Amit? Did something change between qemu 1.5.3 and 2.1.2 which is related to
> the detection of a connect/disconnect to a char device?

No, nothing comes to mind.  RHEL guests work fine according to comment 0, so at least that hints it may not be a qemu issue.

(In reply to Gal Hammer from comment #6)
> After further look, it looks like the problem is with the way the scripts
> works (open a port, write to the port and then close it). It cause either
> qemu or the guest to drop the messages because it assume that there is no
> listener on the other side.
> 
May I know the difference between vioser-test.exe and QE's python scripts for transferring data ?

Thanks,
Mike

(In reply to Mike Cao from comment #8)
> (In reply to Gal Hammer from comment #6)
> > After further look, it looks like the problem is with the way the scripts
> > works (open a port, write to the port and then close it). It cause either
> > qemu or the guest to drop the messages because it assume that there is no
> > listener on the other side.
> > 
> May I know the difference between vioser-test.exe and QE's python scripts
> for transferring data ?
> 
> Thanks,
> Mike

I'm not familiar with vioser-test.exe code. I assume that the difference is because the Python's scripts open and close the port after each read/write.

Vadim ,Can you help to answer comment #8 as you are the author of vioser-test.exe

Thanks in advance,
Mike

vioser-test doesn't close the open handler between the tests. But it's probably not the only difference. The application was designed to test both - blocking and non-blocking IO. By default it is running in non-blocking mode, but it will operate in blocked mode if was started with "-n" flag.

Vadim.

(In reply to Vadim Rozenfeld from comment #11)
> vioser-test doesn't close the open handler between the tests. But it's
> probably not the only difference. The application was designed to test both
> - blocking and non-blocking IO. By default it is running in non-blocking
> mode, but it will operate in blocked mode if was started with "-n" flag.
> 
> Vadim.

Blocking mode is not supported now if I remember clearly.
Mike

guest also hit this issue with virtio-win-1.7.2-2.el6.noarch,so this is not a virtio-win regression bug

guest does NOT hit this issue when change the socket backend to "-chardev socket,host=localhost,port=12345,server,nowait,id=chardev0"

steps:
1.boot guest with 
/usr/libexec/qemu-kvm -drive file=win7-32.qcow2,if=none,cache=none,media=disk,format=qcow2,id=disk1 -device ide-drive,id=ide0-0-0,drive=disk1,bootindex=0 -monitor stdio -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:06:7f:f9:56,bus=pci.0,addr=0x4 -boot menu=on -vnc :0 -vga cirrus -chardev file,path=/root/console.log,id=serial1 -device isa-serial,chardev=serial1,id=s1 -usb -device usb-tablet,id=tablet1 -smp 2,cores=2,threads=1,sockets=1 -m 2G -enable-kvm -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -device virtio-serial-pci,id=virtio-serial0,max_ports=31,bus=pci.0 -chardev socket,host=localhost,port=12345,server,nowait,id=chardev0 -device virtserialport,chardev=chardev0,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port0

2.Transferring data form host to guest via port0
Guest: 
python VirtIOChannel_guest_reieve.py com.redhat.rhevm.vdsm
Host: 
2.1 modify serial-host-send.py script
#vport = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) ---> commented out
#vport.connect(sys.argv[1])                                ---> commented out
vport = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
vport.connect((HOST, PORT))
2.2 python serial-host-send.py

Actual result:
guest can receive data correctly.

Based on above ,this is qemu-kvm-rhev regression bug

rhel guest didnot hit this issue in comment #0 is due to QE use "nc -U" to transfer data instead of using the python scripts.
QE retest with python script,rhel7.1 guest also hit this issue：guest cannot receive data with unix socket and works fine with tcp socket.

Regardless of the regression ...
The issue is that the Windows guest is doing a blocking read, but the definition of read is not clear, and the current behavior is:
- If there is a connection from the host, then the guest will block, waiting for data to arrive.
- If there is no connection, the guest does not block (wait for a connection), and exits right away.
The test script on the host repeatedly "connects, sends data, and disconnects", so if the guest reads the data when the host is disconnected then the data is lost.
Deferring to 7.2, Regardless of the proper solution.

Comment 17 indicates that the issue is in QEMU. Reassigning to Amit.
As I wrote in comment 18, I am not sure that there is a bug.

This is another bug that doesn't work for connect, send, disconnect, repeat sequences.  We need a better io loop in qemu (esp. we need to detect POLLHUP, and terminate a connection).  The host doesn't realise the chardev is disconnected, so it just misses new data from the connection.  From comment 15, tcp works fine; so this is specific to unix chardevs.  That's strange.

Reproduced this issue on qemu-kvm-rhev-2.1.2-23.el7_1.1.x86_64.

Verified this issue on qemu-kvm-rhev-2.5.0-1.el7.x86_64, didnot hit this issue. the issue has been fixed.

Best Regards~
Peixiu Hou

(In reply to Peixiu Hou from comment #27)
> Reproduced this issue on qemu-kvm-rhev-2.1.2-23.el7_1.1.x86_64.
> 
> Verified this issue on qemu-kvm-rhev-2.5.0-1.el7.x86_64, didnot hit this
> issue. the issue has been fixed.

Thanks!

Closing.

Verify this bug on qemu-kvm-rhev-2.6.0-21.el7.x86_64

Steps are same as comment#0,guest/host can transfer data via unix socket backend.

So this issue has been fixed already,change status to verified.

RHEL guest: reproduced with qemu-kvm-rhev-2.1.2-23.el7.x86_64 and verified with qemu-kvm-rhev-2.6.0-23.el7.x86_64.

Version-Release number of selected component (if applicable):
kernel: 3.10.0-500.el7.x86_64 (both host and guest)
seabios-1.9.1-4.el7.x86_64

Steps are same as comment 0.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2673.html