search for: nr_active_ports

...ct virtio_device *vdev = virtserial.vdev; + u32 i, port_nr; + int ret; + + virtserconf = kmalloc(sizeof(struct virtio_serial_config) + + get_ports_map_size(virtserial.config->max_nr_ports), + GFP_KERNEL); + vdev->config->get(vdev, + offsetof(struct virtio_serial_config, nr_active_ports), + &virtserconf->nr_active_ports, + sizeof(virtserconf->nr_active_ports)); + vdev->config->get(vdev, + offsetof(struct virtio_serial_config, ports_map), + virtserconf->ports_map, + get_ports_map_size(virtserial.config->max_nr_ports)); + + /* Hot-add ports...

...ct virtio_device *vdev = virtserial.vdev; + u32 i, port_nr; + int ret; + + virtserconf = kmalloc(sizeof(struct virtio_serial_config) + + get_ports_map_size(virtserial.config->max_nr_ports), + GFP_KERNEL); + vdev->config->get(vdev, + offsetof(struct virtio_serial_config, nr_active_ports), + &virtserconf->nr_active_ports, + sizeof(virtserconf->nr_active_ports)); + vdev->config->get(vdev, + offsetof(struct virtio_serial_config, ports_map), + virtserconf->ports_map, + get_ports_map_size(virtserial.config->max_nr_ports)); + + /* Hot-add ports...

Hello, This series fixes a few issues pointed out by Avi and Juan. Avi pointed out we should do full scatter/gather processing of guest data even if current (well-behaved) guests don't send multiple iovs per element. Juan pointed out a few migration-related bugs. In handling the migration fixes, I noticed hot-plug/unplug isn't handled perfectly for the migration case: ports are

Hello, This series fixes a few issues pointed out by Avi and Juan. Avi pointed out we should do full scatter/gather processing of guest data even if current (well-behaved) guests don't send multiple iovs per element. Juan pointed out a few migration-related bugs. In handling the migration fixes, I noticed hot-plug/unplug isn't handled perfectly for the migration case: ports are

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 all, Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain backward compatibility, the first port to be spawned (port at id 0) is to be a console port, to be bound to hvc. This keeps new

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain backward compatibility, the first port to be spawned (port at id 0) is to be a console port, to be bound to hvc. This keeps new

...when new ports are added + */ +static void virtio_console_config_work_handler(struct work_struct *work) +{ + struct virtio_console_config virtconconf; + struct virtio_device *vdev = virtconsole.vdev; + u32 i; + int ret; + + vdev->config->get(vdev, + offsetof(struct virtio_console_config, nr_active_ports), + &virtconconf.nr_active_ports, + sizeof(virtconconf.nr_active_ports)); + + /* Hot-add ports */ + for (i = virtconsole.config.nr_active_ports; + i < virtconconf.nr_active_ports; i++) { + ret = virtconsole_add_port(virtconsole.config.nr_active_ports + i); + if (!ret) + virt...

...when new ports are added + */ +static void virtio_console_config_work_handler(struct work_struct *work) +{ + struct virtio_console_config virtconconf; + struct virtio_device *vdev = virtconsole.vdev; + u32 i; + int ret; + + vdev->config->get(vdev, + offsetof(struct virtio_console_config, nr_active_ports), + &virtconconf.nr_active_ports, + sizeof(virtconconf.nr_active_ports)); + + /* Hot-add ports */ + for (i = virtconsole.config.nr_active_ports; + i < virtconconf.nr_active_ports; i++) { + ret = virtconsole_add_port(virtconsole.config.nr_active_ports + i); + if (!ret) + virt...

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain backward compatibility, the first port to be spawned (port at id 0) is to be a console port, to be bound to hvc. This keeps new

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain backward compatibility, the first port to be spawned (port at id 0) is to be a console port, to be bound to hvc. This keeps new

(Rusty, would it improve the chances of getting this patch in your tree if this description were written with latex instead of without it?) Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain

(Rusty, would it improve the chances of getting this patch in your tree if this description were written with latex instead of without it?) Here is a new iteration of the patch series that implements a transport for guest and host communications. I've tested for compatibility (old qemu & new kernel, new qemu & old kernel, new qemu & new kernel) and it all works fine. To maintain

Hello, This is the patch that I have for adding support for multiple ports to virtio_console. It's pretty stable in my testing so far and the memory corruption that I had earlier has been resolved in linux-next so I'm proposing this for inclusion. This currently uses device major number 60 from the experimental range; Alan could you please reserve a new major number for virtio_console?

Hello, This is the patch that I have for adding support for multiple ports to virtio_console. It's pretty stable in my testing so far and the memory corruption that I had earlier has been resolved in linux-next so I'm proposing this for inclusion. This currently uses device major number 60 from the experimental range; Alan could you please reserve a new major number for virtio_console?

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. 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 todo list but this works well. New since last send: - live migration support** - write path in the guest

Hello all, Here is a new iteration of the patch series that implements a transport for guest and host communications. 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 todo list but this works well. New since last send: - live migration support** - write path in the guest

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