similar to: [PATCH] virtio_serial: A char device for simple guest <-> host communication

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

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, Here are two patches. One implements a virtio-serial device in qemu and the other is the driver for a guest kernel. While working on a vmchannel interface that is needed for communication between guest userspace and host userspace, I saw that most of the interface can be abstracted out as a "serial" device with "ports". Some requirements for a vmchannel are listed at

Hello, Here are two patches. One implements a virtio-serial device in qemu and the other is the driver for a guest kernel. While working on a vmchannel interface that is needed for communication between guest userspace and host userspace, I saw that most of the interface can be abstracted out as a "serial" device with "ports". Some requirements for a vmchannel are listed at

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 when

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 when

Other drives might want to use SCSI command emulation without going through the SCSI disk abstraction, as this imposes too many limits on the emulation. Signed-off-by: Hannes Reinecke <hare at suse.de> --- block.c | 15 ++ block.h | 3 + block_int.h | 1 + hw/scsi-disk.c | 610 ++++++++++++++++++++++++++++++-------------------------- hw/scsi-disk.h | 3 + 5

Other drives might want to use SCSI command emulation without going through the SCSI disk abstraction, as this imposes too many limits on the emulation. Signed-off-by: Hannes Reinecke <hare at suse.de> --- block.c | 15 ++ block.h | 3 + block_int.h | 1 + hw/scsi-disk.c | 610 ++++++++++++++++++++++++++++++-------------------------- hw/scsi-disk.h | 3 + 5

PCI devices don't exist/work. You would see errors such as: qemu-system-s390x: -device virtio-rng-pci,rng=rng0: MSI-X support is mandatory in the S390 architecture --- lib/guestfs-internal.h | 38 +++++++++++++++++++++++++++++--------- lib/launch-direct.c | 4 ++-- 2 files changed, 31 insertions(+), 11 deletions(-) diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h index

Thanks: Laine Stump, Andrea Bolognani, Marcel Apfelbaum. --- src/guestfs-internal.h | 6 +++--- src/launch-libvirt.c | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 44 insertions(+), 3 deletions(-) diff --git a/src/guestfs-internal.h b/src/guestfs-internal.h index d437b9a..428da7f 100644 --- a/src/guestfs-internal.h +++ b/src/guestfs-internal.h @@ -137,17 +137,17 @@ /*

Hey Rusty, This patchset is on top of the previous one. It sends a SIGIO signal to apps that request signals for host activity. SIGIO is sent on host connect, disconnect as well as hot-unplug (which can be seen as a special case of host disconnect). Tested using several testcases in the test-virtserial repo: http://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git Please apply.

Hey Rusty, This patchset is on top of the previous one. It sends a SIGIO signal to apps that request signals for host activity. SIGIO is sent on host connect, disconnect as well as hot-unplug (which can be seen as a special case of host disconnect). Tested using several testcases in the test-virtserial repo: http://fedorapeople.org/gitweb?p=amitshah/public_git/test-virtserial.git Please apply.

Hi Rusty, The main thing in these patches is the introduction of injecting SIGIO on host-side connect/disconnect events and when new data is available for ports. The first two patches fix bugs that I haven't seen, but look like the right thing to do. These have been tested extensively using the test-virtserial test suite. Please apply, Amit. Amit Shah (4): virtio: console: Un-block

Hi Rusty, The main thing in these patches is the introduction of injecting SIGIO on host-side connect/disconnect events and when new data is available for ports. The first two patches fix bugs that I haven't seen, but look like the right thing to do. These have been tested extensively using the test-virtserial test suite. Please apply, Amit. Amit Shah (4): virtio: console: Un-block

We're never going to use virtio-console since, although it is faster, it's not available during early boot, and that is more important for debugging. --- src/launch-direct.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/src/launch-direct.c b/src/launch-direct.c index a81d4b3..f1fe92b 100644 --- a/src/launch-direct.c +++ b/src/launch-direct.c @@ -574,19 +574,9 @@

We're never going to use virtio-console since, although it is faster, it's not available during early boot, and that is more important for debugging. --- src/launch-direct.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/src/launch-direct.c b/src/launch-direct.c index a81d4b3..e8450e1 100644 --- a/src/launch-direct.c +++ b/src/launch-direct.c @@ -574,19

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