search for: virtio_console_config

...ck); -} - static void in_intr(struct virtqueue *vq) { struct port *port; @@ -1206,62 +1042,6 @@ fail: return err; } -/* - * The workhandler for config-space updates. - * - * This is called when ports are hot-added. - */ -static void config_work_handler(struct work_struct *work) -{ - struct virtio_console_config virtconconf; - struct ports_device *portdev; - struct virtio_device *vdev; - int err; - - portdev = container_of(work, struct ports_device, config_work); - - vdev = portdev->vdev; - vdev->config->get(vdev, - offsetof(struct virtio_console_config, nr_ports), - &virtconconf.nr_po...

...ck); -} - static void in_intr(struct virtqueue *vq) { struct port *port; @@ -1206,62 +1042,6 @@ fail: return err; } -/* - * The workhandler for config-space updates. - * - * This is called when ports are hot-added. - */ -static void config_work_handler(struct work_struct *work) -{ - struct virtio_console_config virtconconf; - struct ports_device *portdev; - struct virtio_device *vdev; - int err; - - portdev = container_of(work, struct ports_device, config_work); - - vdev = portdev->vdev; - vdev->config->get(vdev, - offsetof(struct virtio_console_config, nr_ports), - &virtconconf.nr_po...

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

struct ports_device includes a config field including the whole virtio_console_config, but only max_nr_ports in there is ever updated or used. The rest is unused and in fact does not even mirror the device config. Drop everything except max_nr_ports, saving some memory. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/char/virtio_console.c | 14 +++++++------...

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

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

...irtio_device *vdev) { struct ports_device *portdev; int err; @@ -1724,10 +1804,12 @@ static int __devinit virtcons_probe(struct virtio_device *vdev) multiport = false; portdev->config.max_nr_ports = 1; - if (virtio_config_val(vdev, VIRTIO_CONSOLE_F_MULTIPORT, - offsetof(struct virtio_console_config, - max_nr_ports), - &portdev->config.max_nr_ports) == 0) + if (is_rproc_serial(vdev)) + multiport = false; + else if (virtio_config_val(vdev, VIRTIO_CONSOLE_F_MULTIPORT, + offsetof(struct virtio_console_config, + max_nr_ports), + &portdev->config.ma...

...irtio_device *vdev) { struct ports_device *portdev; int err; @@ -1724,10 +1804,12 @@ static int __devinit virtcons_probe(struct virtio_device *vdev) multiport = false; portdev->config.max_nr_ports = 1; - if (virtio_config_val(vdev, VIRTIO_CONSOLE_F_MULTIPORT, - offsetof(struct virtio_console_config, - max_nr_ports), - &portdev->config.max_nr_ports) == 0) + if (is_rproc_serial(vdev)) + multiport = false; + else if (virtio_config_val(vdev, VIRTIO_CONSOLE_F_MULTIPORT, + offsetof(struct virtio_console_config, + max_nr_ports), + &portdev->config.ma...

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.

...ndler(struct work_struct *work) +{ + struct ports_device *portdev; + + portdev = container_of(work, struct ports_device, control_work); if (!use_multiport(portdev)) { + struct virtio_device *vdev; struct port *port; u16 rows, cols; + vdev = portdev->vdev; virtio_cread(vdev, struct virtio_console_config, cols, &cols); virtio_cread(vdev, struct virtio_console_config, rows, &rows); @@ -2040,6 +2052,7 @@ static int virtcons_probe(struct virtio_device *vdev) virtio_device_ready(portdev->vdev); + INIT_WORK(&portdev->config_work, &config_work_handler); INIT_WORK(&p...

...ndler(struct work_struct *work) +{ + struct ports_device *portdev; + + portdev = container_of(work, struct ports_device, control_work); if (!use_multiport(portdev)) { + struct virtio_device *vdev; struct port *port; u16 rows, cols; + vdev = portdev->vdev; virtio_cread(vdev, struct virtio_console_config, cols, &cols); virtio_cread(vdev, struct virtio_console_config, rows, &rows); @@ -2040,6 +2052,7 @@ static int virtcons_probe(struct virtio_device *vdev) virtio_device_ready(portdev->vdev); + INIT_WORK(&portdev->config_work, &config_work_handler); INIT_WORK(&p...

...e.c @@ -1675,13 +1675,11 @@ static int __devinit virtcons_probe(struct virtio_device *vdev) multiport = false; portdev->config.max_nr_ports = 1; - if (virtio_has_feature(vdev, VIRTIO_CONSOLE_F_MULTIPORT)) { + if (virtio_config_val(vdev, VIRTIO_CONSOLE_F_MULTIPORT, + offsetof(struct virtio_console_config, + max_nr_ports), + &portdev->config.max_nr_ports) == 0) multiport = true; - vdev->config->get(vdev, offsetof(struct virtio_console_config, - max_nr_ports), - &portdev->config.max_nr_ports, - sizeof(portdev->config.max_nr_ports)); - }...

...e.c @@ -1675,13 +1675,11 @@ static int __devinit virtcons_probe(struct virtio_device *vdev) multiport = false; portdev->config.max_nr_ports = 1; - if (virtio_has_feature(vdev, VIRTIO_CONSOLE_F_MULTIPORT)) { + if (virtio_config_val(vdev, VIRTIO_CONSOLE_F_MULTIPORT, + offsetof(struct virtio_console_config, + max_nr_ports), + &portdev->config.max_nr_ports) == 0) multiport = true; - vdev->config->get(vdev, offsetof(struct virtio_console_config, - max_nr_ports), - &portdev->config.max_nr_ports, - sizeof(portdev->config.max_nr_ports)); - }...

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