search for: vport0p1

Hi All, In my Windows 7 Pro 64 bit KVM virtual machine, I have a hidden device driver called "vport0p1". What driver goes with this? Many thanks, -T

...type="virtio" name="org.qemu.guest_agent.0" state="connected"/> </channel> Host# virsh attach-device instance guest-agent.xml Host# virsh detach-device instance guest-agent.xml Host# virsh attach-device instance guest-agent.xml and guest report: virtio-ports vport0p1: Error allocating inbufs The reason is that the port is unplugged and the vq buf still remained. So, fix two cases in this patch: 1, fix memory leak with attach-device/detach-device. 2, fix logic bug with attach-device/detach-device/attach-device. Signed-off-by: zhenwei pi <pizhenwei at byteda...

...type="virtio" name="org.qemu.guest_agent.0" state="connected"/> </channel> Host# virsh attach-device instance guest-agent.xml Host# virsh detach-device instance guest-agent.xml Host# virsh attach-device instance guest-agent.xml and guest report: virtio-ports vport0p1: Error allocating inbufs The reason is that the port is unplugged and the vq buf still remained. So, fix two cases in this patch: 1, fix memory leak with attach-device/detach-device. 2, fix logic bug with attach-device/detach-device/attach-device. Signed-off-by: zhenwei pi <pizhenwei at byteda...

You can see that currently we leak the virtio-serial file descriptor into child processes. ><fs> debug fds '' 0 /dev/console 1 /dev/console 2 /dev/console 3 /dev/vport0p1 4 /proc/252/fd ><fs> debug sh 'ls -l /proc/self/fd' total 0 lr-x------ 1 root root 64 Aug 27 15:14 0 -> /dev/null l-wx------ 1 root root 64 Aug 27 15:14 1 -> pipe:[5124] l-wx------ 1 root root 64 Aug 27 15:14 2 -> pipe:[5124] lrwx------ 1 root root 64 Aug 27 15:14 3 -&gt...

The in-vq operations were protected by a lock, but the out-vq operations were not. This caused panics / errors as described in patch 2. Fix that. The first patch renames the existing cvq_lock to c_ivq_lock to match c_ivq. The second patch introduces the c_ovq_lock for the c_ovq. Please apply. I also believe this is a candidate for stable. Amit Shah (2): virtio: console: rename cvq_lock

The in-vq operations were protected by a lock, but the out-vq operations were not. This caused panics / errors as described in patch 2. Fix that. The first patch renames the existing cvq_lock to c_ivq_lock to match c_ivq. The second patch introduces the c_ovq_lock for the c_ovq. Please apply. I also believe this is a candidate for stable. Amit Shah (2): virtio: console: rename cvq_lock

The in-vq operations were protected by a lock, but the out-vq operations were not. This caused panics / errors as described in patch 2. Fix that. The first patch renames the existing cvq_lock to c_ivq_lock to match c_ivq. The second patch introduces the c_ovq_lock for the c_ovq. Please apply. I also believe this is a candidate for stable. v2: * Use spin_lock instead of spin_lock_irq.

The in-vq operations were protected by a lock, but the out-vq operations were not. This caused panics / errors as described in patch 2. Fix that. The first patch renames the existing cvq_lock to c_ivq_lock to match c_ivq. The second patch introduces the c_ovq_lock for the c_ovq. Please apply. I also believe this is a candidate for stable. v2: * Use spin_lock instead of spin_lock_irq.

...rw------- 1 root root 7, 128 Feb 23 18:17 vcsa crw------- 1 root root 7, 129 Feb 23 18:17 vcsa1 brw------- 1 root root 254, 0 Feb 23 18:17 vda brw------- 1 root root 254, 16 Feb 23 18:17 vdb crw------- 1 root root 10, 63 Feb 23 18:17 vga_arbiter crw------- 1 root root 252, 1 Feb 23 18:17 vport0p1 crw-rw-rw- 1 root root 1, 5 Feb 23 18:17 zero /dev/char: total 0 lrwxrwxrwx 1 root root 17 Feb 23 18:17 10:236 -> ../mapper/control /dev/cpu: total 0 c--------- 1 root root 10, 184 Feb 23 18:17 microcode /dev/input: total 0 crw------- 1 root root 13, 63 Feb 23 18:17 mice /dev/mapper: tot...

...type="virtio" name="org.qemu.guest_agent.0" state="connected"/> </channel> Host# virsh attach-device instance guest-agent.xml Host# virsh detach-device instance guest-agent.xml Host# virsh attach-device instance guest-agent.xml and guest report: virtio-ports vport0p1: Error allocating inbufs The reason is that the port is unplugged and the vq buf still remained. So, fix two cases in this patch: 1, fix memory leak with attach-device/detach-device. 2, fix logic bug with attach-device/detach-device/attach-device. Signed-off-by: zhenwei pi <pizhenwei at byteda...

..."org.qemu.guest_agent.0" state="connected"/> > </channel> > Host# virsh attach-device instance guest-agent.xml > Host# virsh detach-device instance guest-agent.xml > Host# virsh attach-device instance guest-agent.xml > > and guest report: virtio-ports vport0p1: Error allocating inbufs > > The reason is that the port is unplugged and the vq buf still remained. > So, fix two cases in this patch: > 1, fix memory leak with attach-device/detach-device. > 2, fix logic bug with attach-device/detach-device/attach-device. > > Signed-off-by:...

...</channel> 2. Use scripts,run this scripts is no error output #!/usr/bin/python import socket s=socket.socket(socket.AF_UNIX,socket.SOCK_STREAM) s.connect("/var/lib/libvirt/qemu/r-22-VM.agent") s.send("test\n") s.close 3. But i not read date in vm device /dev/vport0p1 (vm is run) My version, libvirt: 1.2.13.1 qmeu: 2.3.0 system: centos 6.5 This test in libvirt 1.0.5.7 qemu 1.5.3 is success. Please help , thanks

...resulted in a warning message like this one: -------------------8<--------------------------------------- WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xc9/0x130() (Not tainted) Hardware name: KVM sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:04.0/virtio0/virtio-ports/vport0p1' Call Trace: [<ffffffff8106b607>] ? warn_slowpath_common+0x87/0xc0 [<ffffffff8106b6f6>] ? warn_slowpath_fmt+0x46/0x50 [<ffffffff811f2319>] ? sysfs_add_one+0xc9/0x130 [<ffffffff811f23e8>] ? create_dir+0x68/0xb0 [<ffffffff811f2469>] ? sysfs_create_dir+0x39/0x50...

...resulted in a warning message like this one: -------------------8<--------------------------------------- WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xc9/0x130() (Not tainted) Hardware name: KVM sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:04.0/virtio0/virtio-ports/vport0p1' Call Trace: [<ffffffff8106b607>] ? warn_slowpath_common+0x87/0xc0 [<ffffffff8106b6f6>] ? warn_slowpath_fmt+0x46/0x50 [<ffffffff811f2319>] ? sysfs_add_one+0xc9/0x130 [<ffffffff811f23e8>] ? create_dir+0x68/0xb0 [<ffffffff811f2469>] ? sysfs_create_dir+0x39/0x50...

...like this one: > > -------------------8<--------------------------------------- > WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xc9/0x130() (Not tainted) > Hardware name: KVM > sysfs: cannot create duplicate filename > '/devices/pci0000:00/0000:00:04.0/virtio0/virtio-ports/vport0p1' > > Call Trace: > [<ffffffff8106b607>] ? warn_slowpath_common+0x87/0xc0 > [<ffffffff8106b6f6>] ? warn_slowpath_fmt+0x46/0x50 > [<ffffffff811f2319>] ? sysfs_add_one+0xc9/0x130 > [<ffffffff811f23e8>] ? create_dir+0x68/0xb0 > [<ffffffff811f2469...

...like this one: > > -------------------8<--------------------------------------- > WARNING: at fs/sysfs/dir.c:512 sysfs_add_one+0xc9/0x130() (Not tainted) > Hardware name: KVM > sysfs: cannot create duplicate filename > '/devices/pci0000:00/0000:00:04.0/virtio0/virtio-ports/vport0p1' > > Call Trace: > [<ffffffff8106b607>] ? warn_slowpath_common+0x87/0xc0 > [<ffffffff8106b6f6>] ? warn_slowpath_fmt+0x46/0x50 > [<ffffffff811f2319>] ? sysfs_add_one+0xc9/0x130 > [<ffffffff811f23e8>] ? create_dir+0x68/0xb0 > [<ffffffff811f2469...

Hello, This series fixes a few races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches for

Hello, This series fixes a few races with port unplug and the various file operations: read(), write(), close() and poll(). There still might be more races lurking, but testing this series looks good to at least solve the easily-triggerable ones. I've run the virtio-serial testsuite and a few open/close/unplug tests, and haven't seen any badness. I've marked these patches for

...7, 0 Jan 1 00:00 vcs crw------- 1 0 0 7, 1 Jan 1 00:00 vcs1 crw------- 1 0 0 7, 128 Jan 1 00:00 vcsa crw------- 1 0 0 7, 129 Jan 1 00:00 vcsa1 crw------- 1 0 0 10, 63 Jan 1 00:00 vga_arbiter drwxr-xr-x 2 0 0 60 Jan 1 00:00 virtio-ports crw------- 1 0 0 252, 1 Jan 1 00:00 vport0p1 crw-rw-rw- 1 0 0 1, 5 Jan 1 00:00 zero /dev/block: total 0 lrwxrwxrwx 1 0 0 7 Jan 1 00:00 1:0 -> ../ram0 lrwxrwxrwx 1 0 0 7 Jan 1 00:00 1:1 -> ../ram1 lrwxrwxrwx 1 0 0 8 Jan 1 00:00 1:10 -> ../ram10 lrwxrwxrwx 1 0 0 8 Jan 1 00:00 1:11 -> ../ram11 lrwxrwxrwx 1 0 0 8 Jan 1 00:0...

Hello, This series fixes a few bugs and races with port unplug and the various file operations: read(), write() and close(). I started coding up an alternative locking mechanism based on the discussion earlier in this series, but some of what we already have has to remain, and the new code is sufficiently different, so I'd rather it bakes for a while, and I ensure there are no regressions