similar to: virtio-serial: A guest <-> host interface for simple communication

Hello, This is a new iteration of the patches that implement virtio-serial. Changes include: * Adding support for port hot-add * Creating ports at specific ids that can be bound to specific apps / usage * Cleanups This code still doesn't get rid of the support for assigning names to ports but it just has to be ripped out. Comments welcome. Thanks, Amit.

Hello, This is a new iteration of the patches that implement virtio-serial. Changes include: * Adding support for port hot-add * Creating ports at specific ids that can be bound to specific apps / usage * Cleanups This code still doesn't get rid of the support for assigning names to ports but it just has to be ripped out. Comments welcome. Thanks, Amit.

Hello all, This are the latest version of the patches. Lots of things have changed since the last submission. A few of which I remember: - VNC copy / paste works* (* conditions apply) - client vnc copies get propagated to guest port 3 (/dev/vmch3) - guest writes to port 3 (/dev/vmch3) go straight to client's clipboard - sysfs hooks to autodiscover ports - support for 64 ports in this

Hello all, This are the latest version of the patches. Lots of things have changed since the last submission. A few of which I remember: - VNC copy / paste works* (* conditions apply) - client vnc copies get propagated to guest port 3 (/dev/vmch3) - guest writes to port 3 (/dev/vmch3) go straight to client's clipboard - sysfs hooks to autodiscover ports - support for 64 ports in this

We expose multiple char devices ("ports") for simple communication between the host userspace and guest. Sample offline usages can be: poking around in a guest to find out the file systems used, applications installed, etc. Online usages can be sharing of clipboard data between the guest and the host, sending information about logged-in users to the host, locking the screen or session

We expose multiple char devices ("ports") for simple communication between the host userspace and guest. Sample offline usages can be: poking around in a guest to find out the file systems used, applications installed, etc. Online usages can be sharing of clipboard data between the guest and the host, sending information about logged-in users to the host, locking the screen or session

Hey Rusty, These updated patches in the series return -EFAULT on copy_xx_user errors and also move the copy_from_user into fops_write() instead of it being in send_buf. This enables send_buf to just read from kernel buffers, making it simpler. This also allows write()s to write more to the host in one go, removingthe 4k limitation. I do limit the writes to 32k at once to not put too much

Hey Rusty, These updated patches in the series return -EFAULT on copy_xx_user errors and also move the copy_from_user into fops_write() instead of it being in send_buf. This enables send_buf to just read from kernel buffers, making it simpler. This also allows write()s to write more to the host in one go, removingthe 4k limitation. I do limit the writes to 32k at once to not put too much

Hello, This series reworks the ABI to allow port discovery (only) via the control queue and enable multiport again. In addition, it adds support for non-blocking write() support, which means no spinning. This works fine with the recent patches that are on qemu-devel. Also included is removal of hvc_remove() as removing one such console port causes other console ports (registered with hvc) to

Hello, This series reworks the ABI to allow port discovery (only) via the control queue and enable multiport again. In addition, it adds support for non-blocking write() support, which means no spinning. This works fine with the recent patches that are on qemu-devel. Also included is removal of hvc_remove() as removing one such console port causes other console ports (registered with hvc) to

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. The code has been updated to reuse the virtio-console device instead of creating a new virtio-serial device. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. There are a few items on my

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. The code has been updated to reuse the virtio-console device instead of creating a new virtio-serial device. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. There are a few items on my

Thanks: Cole Robinson, Dan Horak, Thomas Huth. --- lib/launch-libvirt.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/lib/launch-libvirt.c b/lib/launch-libvirt.c index f66c8e0ef..4adb2cfb3 100644 --- a/lib/launch-libvirt.c +++ b/lib/launch-libvirt.c @@ -1359,6 +1359,7 @@ construct_libvirt_xml_devices (guestfs_h *g, return -1; } +#ifndef __s390x__ /*

I run latest sparse from git on virtio drivers (turns out the version I had was rather outdated). This patchset fixes a couple of bugs this uncovered, and adds some annotations to make it sparse-clean. In particular, endian-ness is often tricky, so this patchset enabled endian-ness checks for sparse builds. Michael S. Tsirkin (10): virtio_console: drop unused config fields drm/virtio: fix

I run latest sparse from git on virtio drivers (turns out the version I had was rather outdated). This patchset fixes a couple of bugs this uncovered, and adds some annotations to make it sparse-clean. In particular, endian-ness is often tricky, so this patchset enabled endian-ness checks for sparse builds. Michael S. Tsirkin (10): virtio_console: drop unused config fields drm/virtio: fix

Unfortunately there proved to be at least one bug which requires an ABI change, so we're best off not introducing multiport support until 2.6.35. While I generally left the multiport code paths intact, I really wanted to remove the ABI defines from the header, which meant some quite deep cuts. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> To: Amit Shah <amit.shah at

Unfortunately there proved to be at least one bug which requires an ABI change, so we're best off not introducing multiport support until 2.6.35. While I generally left the multiport code paths intact, I really wanted to remove the ABI defines from the header, which meant some quite deep cuts. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> To: Amit Shah <amit.shah at

Hi, Sorry for the late reply. On (Thu) 12 Jan 2012 [09:20:07], zanghongyong at huawei.com wrote: > From: Hongyong Zang <zanghongyong at huawei.com> > > Add setup_port_vq(). Create the io ports' vqs when add_port. Can you describe the changes in more detail, please? > Signed-off-by: Hongyong Zang <zanghongyong at huawei.com> > --- >

Hi, Sorry for the late reply. On (Thu) 12 Jan 2012 [09:20:07], zanghongyong at huawei.com wrote: > From: Hongyong Zang <zanghongyong at huawei.com> > > Add setup_port_vq(). Create the io ports' vqs when add_port. Can you describe the changes in more detail, please? > Signed-off-by: Hongyong Zang <zanghongyong at huawei.com> > --- >

This patch causes aarch64 to use virtio-pci instead of virtio-mmio. Virtio-pci is considerably faster than virtio-mmio, it's more like how other architectures work, and it supports hotplugging (although it's not likely we'd use the latter feature). I'm not necessarily suggesting that we apply this. Laine (CC'd) has some further patches to libvirt lined up which AIUI would