Bug 759975

Libvirt is not involved in the data transfer - it is purely QEMU level, so re-assigning the bug.

(In reply to comment #0)
> Description of problem:
>  guest's pty channel lose at least 50% data when use vport send data to host

>       <channel type='pty'>
>         <source path='/dev/pts/6'/>
>         <target type='virtio' name='org.linux-kvm.port.1'/>
>             <alias name='channel0'/>
>             <address type='virtio-serial' controller='0' bus='0' port='0'/>
>       </channel>

Why are you using port number 0?  That is reserved for console usage.  Use a number greater than 0 and let us know if it still reproduces.

(In reply to comment #3)
> Why are you using port number 0?  That is reserved for console usage.  Use a
> number greater than 0 and let us know if it still reproduces.

  I used port 1 and i tested for more than 10000 times.It passed.
  The xml is:
     <channel type='pty'>
      <source path='/dev/pts/3'/>
      <target type='virtio' name='org.linux-kvm.port.1'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
     </channel>

But i found a new problem:

Scene 1(first echo, then cat):
1.reboot the host and guest make sure the environment is clean.
2.in guest run:
  # echo test1 > /dev/vport0p1
  in host run:
  # cat /dev/pts/3  (you will get nothing)  --->result is not expected
3.Ctrl+C to interrupt "cat" in Step 2
4.swap steps:
  in host run:
  # cat /dev/pts/3
  in guest run:
  # echo test2 > /dev/vport0p1
  in host you will get nothing              --->result is not expected

Scene 2(first cat, then echo):
1.reboot the host and guest make sure the environment is clean.
2.in host run:
  # cat /dev/pts/3
  in guest run:
  # echo test1 > /dev/vport0p1
  you can see "test1" in host
3.Ctrl+C to interrupt "cat" in Step 2
4.swap steps:
  in guest run:
  # echo test2 > /dev/vport0p1
  in host run:
  # cat /dev/pts/3
  you can see "test2" in host

So, I think the step2 and step4 of scene1 should be ok like step4 of scene2.

Above comment 5 removed NEEDINFO.

(In reply to comment #5)
> (In reply to comment #3)
> > Why are you using port number 0?  That is reserved for console usage.  Use a
> > number greater than 0 and let us know if it still reproduces.
> 
>   I used port 1 and i tested for more than 10000 times.It passed.
>   The xml is:
>      <channel type='pty'>
>       <source path='/dev/pts/3'/>
>       <target type='virtio' name='org.linux-kvm.port.1'/>
>       <alias name='channel0'/>
>       <address type='virtio-serial' controller='0' bus='0' port='1'/>
>      </channel>
> 
> But i found a new problem:
> 
> Scene 1(first echo, then cat):
> 1.reboot the host and guest make sure the environment is clean.
> 2.in guest run:
>   # echo test1 > /dev/vport0p1
>   in host run:
>   # cat /dev/pts/3  (you will get nothing)  --->result is not expected
> 3.Ctrl+C to interrupt "cat" in Step 2
> 4.swap steps:
>   in host run:
>   # cat /dev/pts/3
>   in guest run:
>   # echo test2 > /dev/vport0p1
>   in host you will get nothing              --->result is not expected
> 
> Scene 2(first cat, then echo):
> 1.reboot the host and guest make sure the environment is clean.
> 2.in host run:
>   # cat /dev/pts/3
>   in guest run:
>   # echo test1 > /dev/vport0p1
>   you can see "test1" in host
> 3.Ctrl+C to interrupt "cat" in Step 2
> 4.swap steps:
>   in guest run:
>   # echo test2 > /dev/vport0p1
>   in host run:
>   # cat /dev/pts/3
>   you can see "test2" in host
> 
> So, I think the step2 and step4 of scene1 should be ok like step4 of scene2.

BTW,I also have a try your scenario1 and scenario2 using 1 instead of 0.works
well. 
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=kvm.

BTW,if you use kvm directly.if you boot guest with port o.guest can not be
booted with the following messages.any mistake,please correct me.
qemu-kvm: -device
virtserialport,bus=virtio-serial0.0,nr=0,chardev=charchannel0,id=channel0,name=kvm:
Port number 0 on virtio-serial devices reserved for virtconsole devices for
backward compatibility.
qemu-kvm: -device
virtserialport,bus=virtio-serial0.0,nr=0,chardev=charchannel0,id=channel0,name=kvm:
Device 'virtserialport' could not be initialized

#/usr/libexec/qemu-kvm -M rhel6.2.0 -enable-kvm -m 2048 -smp
2,sockets=2,cores=1,threads=1 -name win7sp1-64 -uuid
5d371368-1570-4966-925f-6a58262e7df4 -nodefconfig  -rtc
base=localtime,driftfix=slew -no-shutdown -device
virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x4 -drive
file=/root/rhel6.2-64.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,serial=32-b475-8f3486219435,cache=none,werror=stop,rerror=stop,aio=threads
-device
virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
-drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device
ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev
tap,id=hostnet0,vhost=on -device
virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:42:0b:27,bus=pci.0,addr=0x3
-chardev pty,id=charchannel0,path=/dev/pts/6 -device
virtserialport,bus=virtio-serial0.0,nr=0,chardev=charchannel0,id=channel0,name=kvm
-usb -device usb-tablet,id=input0 -vnc :10 -monitor stdio -smbios
type=1,manufacturer="Dell Inc.111111",product="Precision
T1600",version=0.1,serial=34W753X,uuid=4C4C4544-0034-5710-8037-B3C04F353358,sku="Not
Specified",family="Not Specified" -boot menu=on
char device redirected to /dev/pts/3
qemu-kvm: -device
virtserialport,bus=virtio-serial0.0,nr=0,chardev=charchannel0,id=channel0,name=kvm:
Port number 0 on virtio-serial devices reserved for virtconsole devices for
backward compatibility.
qemu-kvm: -device
virtserialport,bus=virtio-serial0.0,nr=0,chardev=charchannel0,id=channel0,name=kvm:
Device 'virtserialport' could not be initialized

(In reply to comment #7)

> BTW,if you use kvm directly.if you boot guest with port o.guest can not be
> booted with the following messages.any mistake,please correct me.
> qemu-kvm: -device
> virtserialport,bus=virtio-serial0.0,nr=0,chardev=charchannel0,id=channel0,name=kvm:
> Port number 0 on virtio-serial devices reserved for virtconsole devices for
> backward compatibility.

That's right, we made sure in recent versions of qemu-kvm that such mistakes of using port 0 with serial ports are not made.  That was done in bug 700511.

(In reply to comment #5)
> (In reply to comment #3)
> > Why are you using port number 0?  That is reserved for console usage.  Use a
> > number greater than 0 and let us know if it still reproduces.
> 
>   I used port 1 and i tested for more than 10000 times.It passed.

Good.

> But i found a new problem:

[snip]

> So, I think the step2 and step4 of scene1 should be ok like step4 of scene2.

As Junyi suggested, can you try the same with a different backend, instead of pty?  Are you sure no other process is using the pty channels you are using?  It would be best to test with unix or tcp sockets.

I test unix socket with comment #5 's step.
Whatever echo or cat first , it works well.

(In reply to comment #10)
> I test unix socket with comment #5 's step.
> Whatever echo or cat first , it works well.

Thanks; perhaps the pty was being used by some other host process in the first case.