[PATCH 0/7] virtio: console: Fixes, new flexible way of discovering ports

[PATCH 0/7] virtio: console: Fixes, new flexible way of discovering ports

[Amit Shah]

Hello all,

This new patchset switches over to using the control queue for port
discovery so that we can stay in sync with the host for port
enumeration and also don't use bitmaps to limit us to config space
sizes.

This changes the ABI, so it would be better to merge this for 2.6.34
so that we don't have to worry about released kernels with the older
ABI.

Amit Shah (7):
  MAINTAINERS: Put the virtio-console entry in correct alphabetical
    order
  virtio: console: Remove config work handler
  virtio: console: Add a __send_control_msg() that can send messages
    without a valid port
  virtio: console: Move code around for future patches
  virtio: console: Use a control message to add ports
  virtio: console: Don't always create a port 0 if using multiport
  virtio: console: Return -EPIPE if port on the host isn't connected

 MAINTAINERS                    |   13 +-
 drivers/char/virtio_console.c  |  418 +++++++++++++++++-----------------------
 include/linux/virtio_console.h |   18 +-
 3 files changed, 191 insertions(+), 258 deletions(-)

[PATCH 1/7] MAINTAINERS: Put the virtio-console entry in correct alphabetical order

[Amit Shah]

Move around the entry for virtio-console to keep the file sorted.

Signed-off-by: Amit Shah <amit.shah@redhat.com>
---
 MAINTAINERS |   13 +++++++------
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 382eaa4..3306429 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2465,12 +2465,6 @@ L:	linuxppc-dev@ozlabs.org
 S:	Odd Fixes
 F:	drivers/char/hvc_*
 
-VIRTIO CONSOLE DRIVER
-M:	Amit Shah <amit.shah@redhat.com>
-L:	virtualization@lists.linux-foundation.org
-S:	Maintained
-F:	drivers/char/virtio_console.c
-
 iSCSI BOOT FIRMWARE TABLE (iBFT) DRIVER
 M:	Peter Jones <pjones@redhat.com>
 M:	Konrad Rzeszutek Wilk <konrad@kernel.org>
@@ -5952,6 +5946,13 @@ S:	Maintained
 F:	Documentation/filesystems/vfat.txt
 F:	fs/fat/
 
+VIRTIO CONSOLE DRIVER
+M:	Amit Shah <amit.shah@redhat.com>
+L:	virtualization@lists.linux-foundation.org
+S:	Maintained
+F:	drivers/char/virtio_console.c
+F:	include/linux/virtio_console.h
+
 VIRTIO HOST (VHOST)
 M:	"Michael S. Tsirkin" <mst@redhat.com>
 L:	kvm@vger.kernel.org
-- 
1.6.2.5

[PATCH 2/7] virtio: console: Remove config work handler

[Amit Shah]

We're going to switch to using control messages for port hot-plug and
initial port discovery. Remove the config work handler which handled
port hot-plug so far.

Signed-off-by: Amit Shah <amit.shah@redhat.com>
---
 drivers/char/virtio_console.c |   64 +----------------------------------------
 1 files changed, 1 insertions(+), 63 deletions(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 44288ce..c7894f3 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -109,7 +109,6 @@ struct ports_device {
 	 * notification
 	 */
 	struct work_struct control_work;
-	struct work_struct config_work;
 
 	struct list_head ports;
 
@@ -1066,10 +1065,7 @@ static void config_intr(struct virtio_device *vdev)
 	struct ports_device *portdev;
 
 	portdev = vdev->priv;
-	if (use_multiport(portdev)) {
-		/* Handle port hot-add */
-		schedule_work(&portdev->config_work);
-	}
+
 	/*
 	 * We'll use this way of resizing only for legacy support.
 	 * For newer userspace (VIRTIO_CONSOLE_F_MULTPORT+), use
@@ -1210,62 +1206,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_ports,
-			  sizeof(virtconconf.nr_ports));
-
-	if (portdev->config.nr_ports == virtconconf.nr_ports) {
-		/*
-		 * Port 0 got hot-added.  Since we already did all the
-		 * other initialisation for it, just tell the Host
-		 * that the port is ready if we find the port.  In
-		 * case the port was hot-removed earlier, we call
-		 * add_port to add the port.
-		 */
-		struct port *port;
-
-		port = find_port_by_id(portdev, 0);
-		if (!port)
-			add_port(portdev, 0);
-		else
-			send_control_msg(port, VIRTIO_CONSOLE_PORT_READY, 1);
-		return;
-	}
-	if (virtconconf.nr_ports > portdev->config.max_nr_ports) {
-		dev_warn(&vdev->dev,
-			 "More ports specified (%u) than allowed (%u)",
-			 portdev->config.nr_ports + 1,
-			 portdev->config.max_nr_ports);
-		return;
-	}
-	if (virtconconf.nr_ports < portdev->config.nr_ports)
-		return;
-
-	/* Hot-add ports */
-	while (virtconconf.nr_ports - portdev->config.nr_ports) {
-		err = add_port(portdev, portdev->config.nr_ports);
-		if (err)
-			break;
-		portdev->config.nr_ports++;
-	}
-}
-
 static int init_vqs(struct ports_device *portdev)
 {
 	vq_callback_t **io_callbacks;
@@ -1458,7 +1398,6 @@ static int __devinit virtcons_probe(struct virtio_device *vdev)
 
 		spin_lock_init(&portdev->cvq_lock);
 		INIT_WORK(&portdev->control_work, &control_work_handler);
-		INIT_WORK(&portdev->config_work, &config_work_handler);
 
 		nr_added_bufs = fill_queue(portdev->c_ivq, &portdev->cvq_lock);
 		if (!nr_added_bufs) {
@@ -1498,7 +1437,6 @@ static void virtcons_remove(struct virtio_device *vdev)
 	portdev = vdev->priv;
 
 	cancel_work_sync(&portdev->control_work);
-	cancel_work_sync(&portdev->config_work);
 
 	list_for_each_entry_safe(port, port2, &portdev->ports, list)
 		remove_port(port);
-- 
1.6.2.5

[PATCH 3/7] virtio: console: Add a __send_control_msg() that can send messages without a valid port

[Amit Shah]

We will introduce control messages that operate on the device as a whole
rather than just ports. Make send_control_msg() a wrapper around
__send_control_msg() which does not need a valid port.

Signed-off-by: Amit Shah <amit.shah@redhat.com>
---
 drivers/char/virtio_console.c |   16 +++++++++++-----
 1 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index c7894f3..99c36d4 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -372,22 +372,22 @@ out:
 	return ret;
 }
 
-static ssize_t send_control_msg(struct port *port, unsigned int event,
-				unsigned int value)
+static ssize_t __send_control_msg(struct ports_device *portdev, u32 port_id,
+				  unsigned int event, unsigned int value)
 {
 	struct scatterlist sg[1];
 	struct virtio_console_control cpkt;
 	struct virtqueue *vq;
 	unsigned int len;
 
-	if (!use_multiport(port->portdev))
+	if (!use_multiport(portdev))
 		return 0;
 
-	cpkt.id = port->id;
+	cpkt.id = port_id;
 	cpkt.event = event;
 	cpkt.value = value;
 
-	vq = port->portdev->c_ovq;
+	vq = portdev->c_ovq;
 
 	sg_init_one(sg, &cpkt, sizeof(cpkt));
 	if (vq->vq_ops->add_buf(vq, sg, 1, 0, &cpkt) >= 0) {
@@ -398,6 +398,12 @@ static ssize_t send_control_msg(struct port *port, unsigned int event,
 	return 0;
 }
 
+static ssize_t send_control_msg(struct port *port, unsigned int event,
+				unsigned int value)
+{
+	return __send_control_msg(port->portdev, port->id, event, value);
+}
+
 static ssize_t send_buf(struct port *port, void *in_buf, size_t in_count)
 {
 	struct scatterlist sg[1];
-- 
1.6.2.5

[PATCH 4/7] virtio: console: Move code around for future patches

[Amit Shah]

We're going to use add_port() from handle_control_message() in the next
patch.

Move the add_port() and fill_queue(), which depends on it, above
handle_control_message() to avoid forward declarations.

Signed-off-by: Amit Shah <amit.shah@redhat.com>
---
 drivers/char/virtio_console.c |  262 ++++++++++++++++++++--------------------
 1 files changed, 131 insertions(+), 131 deletions(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 99c36d4..8056ad9 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -854,6 +854,137 @@ static const struct file_operations port_debugfs_ops = {
 	.read  = debugfs_read,
 };
 
+static unsigned int fill_queue(struct virtqueue *vq, spinlock_t *lock)
+{
+	struct port_buffer *buf;
+	unsigned int nr_added_bufs;
+	int ret;
+
+	nr_added_bufs = 0;
+	do {
+		buf = alloc_buf(PAGE_SIZE);
+		if (!buf)
+			break;
+
+		spin_lock_irq(lock);
+		ret = add_inbuf(vq, buf);
+		if (ret < 0) {
+			spin_unlock_irq(lock);
+			free_buf(buf);
+			break;
+		}
+		nr_added_bufs++;
+		spin_unlock_irq(lock);
+	} while (ret > 0);
+
+	return nr_added_bufs;
+}
+
+static int add_port(struct ports_device *portdev, u32 id)
+{
+	char debugfs_name[16];
+	struct port *port;
+	struct port_buffer *buf;
+	dev_t devt;
+	unsigned int nr_added_bufs;
+	int err;
+
+	port = kmalloc(sizeof(*port), GFP_KERNEL);
+	if (!port) {
+		err = -ENOMEM;
+		goto fail;
+	}
+
+	port->portdev = portdev;
+	port->id = id;
+
+	port->name = NULL;
+	port->inbuf = NULL;
+	port->cons.hvc = NULL;
+
+	port->host_connected = port->guest_connected = false;
+
+	port->in_vq = portdev->in_vqs[port->id];
+	port->out_vq = portdev->out_vqs[port->id];
+
+	cdev_init(&port->cdev, &port_fops);
+
+	devt = MKDEV(portdev->chr_major, id);
+	err = cdev_add(&port->cdev, devt, 1);
+	if (err < 0) {
+		dev_err(&port->portdev->vdev->dev,
+			"Error %d adding cdev for port %u\n", err, id);
+		goto free_port;
+	}
+	port->dev = device_create(pdrvdata.class, &port->portdev->vdev->dev,
+				  devt, port, "vport%up%u",
+				  port->portdev->drv_index, id);
+	if (IS_ERR(port->dev)) {
+		err = PTR_ERR(port->dev);
+		dev_err(&port->portdev->vdev->dev,
+			"Error %d creating device for port %u\n",
+			err, id);
+		goto free_cdev;
+	}
+
+	spin_lock_init(&port->inbuf_lock);
+	init_waitqueue_head(&port->waitqueue);
+
+	/* Fill the in_vq with buffers so the host can send us data. */
+	nr_added_bufs = fill_queue(port->in_vq, &port->inbuf_lock);
+	if (!nr_added_bufs) {
+		dev_err(port->dev, "Error allocating inbufs\n");
+		err = -ENOMEM;
+		goto free_device;
+	}
+
+	/*
+	 * If we're not using multiport support, this has to be a console port
+	 */
+	if (!use_multiport(port->portdev)) {
+		err = init_port_console(port);
+		if (err)
+			goto free_inbufs;
+	}
+
+	spin_lock_irq(&portdev->ports_lock);
+	list_add_tail(&port->list, &port->portdev->ports);
+	spin_unlock_irq(&portdev->ports_lock);
+
+	/*
+	 * Tell the Host we're set so that it can send us various
+	 * configuration parameters for this port (eg, port name,
+	 * caching, whether this is a console port, etc.)
+	 */
+	send_control_msg(port, VIRTIO_CONSOLE_PORT_READY, 1);
+
+	if (pdrvdata.debugfs_dir) {
+		/*
+		 * Finally, create the debugfs file that we can use to
+		 * inspect a port's state at any time
+		 */
+		sprintf(debugfs_name, "vport%up%u",
+			port->portdev->drv_index, id);
+		port->debugfs_file = debugfs_create_file(debugfs_name, 0444,
+							 pdrvdata.debugfs_dir,
+							 port,
+							 &port_debugfs_ops);
+	}
+	return 0;
+
+free_inbufs:
+	while ((buf = port->in_vq->vq_ops->detach_unused_buf(port->in_vq)))
+		free_buf(buf);
+free_device:
+	device_destroy(pdrvdata.class, port->dev->devt);
+free_cdev:
+	cdev_del(&port->cdev);
+free_port:
+	kfree(port);
+fail:
+	return err;
+}
+
 /* Remove all port-specific data. */
 static int remove_port(struct port *port)
 {
@@ -1081,137 +1212,6 @@ static void config_intr(struct virtio_device *vdev)
 	resize_console(find_port_by_id(portdev, 0));
 }
 
-static unsigned int fill_queue(struct virtqueue *vq, spinlock_t *lock)
-{
-	struct port_buffer *buf;
-	unsigned int nr_added_bufs;
-	int ret;
-
-	nr_added_bufs = 0;
-	do {
-		buf = alloc_buf(PAGE_SIZE);
-		if (!buf)
-			break;
-
-		spin_lock_irq(lock);
-		ret = add_inbuf(vq, buf);
-		if (ret < 0) {
-			spin_unlock_irq(lock);
-			free_buf(buf);
-			break;
-		}
-		nr_added_bufs++;
-		spin_unlock_irq(lock);
-	} while (ret > 0);
-
-	return nr_added_bufs;
-}
-
-static int add_port(struct ports_device *portdev, u32 id)
-{
-	char debugfs_name[16];
-	struct port *port;
-	struct port_buffer *buf;
-	dev_t devt;
-	unsigned int nr_added_bufs;
-	int err;
-
-	port = kmalloc(sizeof(*port), GFP_KERNEL);
-	if (!port) {
-		err = -ENOMEM;
-		goto fail;
-	}
-
-	port->portdev = portdev;
-	port->id = id;
-
-	port->name = NULL;
-	port->inbuf = NULL;
-	port->cons.hvc = NULL;
-
-	port->host_connected = port->guest_connected = false;
-
-	port->in_vq = portdev->in_vqs[port->id];
-	port->out_vq = portdev->out_vqs[port->id];
-
-	cdev_init(&port->cdev, &port_fops);
-
-	devt = MKDEV(portdev->chr_major, id);
-	err = cdev_add(&port->cdev, devt, 1);
-	if (err < 0) {
-		dev_err(&port->portdev->vdev->dev,
-			"Error %d adding cdev for port %u\n", err, id);
-		goto free_port;
-	}
-	port->dev = device_create(pdrvdata.class, &port->portdev->vdev->dev,
-				  devt, port, "vport%up%u",
-				  port->portdev->drv_index, id);
-	if (IS_ERR(port->dev)) {
-		err = PTR_ERR(port->dev);
-		dev_err(&port->portdev->vdev->dev,
-			"Error %d creating device for port %u\n",
-			err, id);
-		goto free_cdev;
-	}
-
-	spin_lock_init(&port->inbuf_lock);
-	init_waitqueue_head(&port->waitqueue);
-
-	/* Fill the in_vq with buffers so the host can send us data. */
-	nr_added_bufs = fill_queue(port->in_vq, &port->inbuf_lock);
-	if (!nr_added_bufs) {
-		dev_err(port->dev, "Error allocating inbufs\n");
-		err = -ENOMEM;
-		goto free_device;
-	}
-
-	/*
-	 * If we're not using multiport support, this has to be a console port
-	 */
-	if (!use_multiport(port->portdev)) {
-		err = init_port_console(port);
-		if (err)
-			goto free_inbufs;
-	}
-
-	spin_lock_irq(&portdev->ports_lock);
-	list_add_tail(&port->list, &port->portdev->ports);
-	spin_unlock_irq(&portdev->ports_lock);
-
-	/*
-	 * Tell the Host we're set so that it can send us various
-	 * configuration parameters for this port (eg, port name,
-	 * caching, whether this is a console port, etc.)
-	 */
-	send_control_msg(port, VIRTIO_CONSOLE_PORT_READY, 1);
-
-	if (pdrvdata.debugfs_dir) {
-		/*
-		 * Finally, create the debugfs file that we can use to
-		 * inspect a port's state at any time
-		 */
-		sprintf(debugfs_name, "vport%up%u",
-			port->portdev->drv_index, id);
-		port->debugfs_file = debugfs_create_file(debugfs_name, 0444,
-							 pdrvdata.debugfs_dir,
-							 port,
-							 &port_debugfs_ops);
-	}
-	return 0;
-
-free_inbufs:
-	while ((buf = port->in_vq->vq_ops->detach_unused_buf(port->in_vq)))
-		free_buf(buf);
-free_device:
-	device_destroy(pdrvdata.class, port->dev->devt);
-free_cdev:
-	cdev_del(&port->cdev);
-free_port:
-	kfree(port);
-fail:
-	return err;
-}
-
 static int init_vqs(struct ports_device *portdev)
 {
 	vq_callback_t **io_callbacks;
-- 
1.6.2.5

[PATCH 5/7] virtio: console: Use a control message to add ports

[Amit Shah]

Instead of the host and guest independently enumerating ports, switch to
a control message to add ports where the host supplies the port number
so there's no ambiguity or a possibility of a race between the host and
the guest port numbers.

We now no longer need the 'nr_ports' config value. Since no kernel has
been released with the MULTIPORT changes yet, we have a chance to fiddle
with the config space without adding compatibility features.

This is beneficial for management software, which would now be able to
instantiate ports at known locations and avoid problems that arise with
implicit numbering in the host and the guest. This removes the 'guessing
game' part of it, and management software can now actually indicate
which id to spawn a particular port on.

Signed-off-by: Amit Shah <amit.shah@redhat.com>
---
 drivers/char/virtio_console.c  |   78 +++++++++++++++++----------------------
 include/linux/virtio_console.h |   18 +++++----
 2 files changed, 44 insertions(+), 52 deletions(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 8056ad9..8b67ff1 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1034,7 +1034,7 @@ static void handle_control_message(struct ports_device *portdev,
 	cpkt = (struct virtio_console_control *)(buf->buf + buf->offset);
 
 	port = find_port_by_id(portdev, cpkt->id);
-	if (!port) {
+	if (!port && cpkt->event != VIRTIO_CONSOLE_PORT_ADD) {
 		/* No valid header at start of buffer.  Drop it. */
 		dev_dbg(&portdev->vdev->dev,
 			"Invalid index %u in control packet\n", cpkt->id);
@@ -1042,6 +1042,30 @@ static void handle_control_message(struct ports_device *portdev,
 	}
 
 	switch (cpkt->event) {
+	case VIRTIO_CONSOLE_PORT_ADD:
+		if (port) {
+			/*
+			 * This can happen for port 0: we have to
+			 * create a console port during probe() as was
+			 * the behaviour before the MULTIPORT feature.
+			 * On a newer host, when the host tells us
+			 * that a port 0 is available, we should just
+			 * say we have the port all set up.
+			 */
+			send_control_msg(port, VIRTIO_CONSOLE_PORT_READY, 1);
+			break;
+		}
+		if (cpkt->id >= portdev->config.max_nr_ports) {
+			dev_warn(&portdev->vdev->dev,
+				"Request for adding port with out-of-bound id %u, max. supported id: %u\n",
+				cpkt->id, portdev->config.max_nr_ports - 1);
+			break;
+		}
+		add_port(portdev, cpkt->id);
+		break;
+	case VIRTIO_CONSOLE_PORT_REMOVE:
+		remove_port(port);
+		break;
 	case VIRTIO_CONSOLE_CONSOLE_PORT:
 		if (!cpkt->value)
 			break;
@@ -1100,32 +1124,6 @@ static void handle_control_message(struct ports_device *portdev,
 			kobject_uevent(&port->dev->kobj, KOBJ_CHANGE);
 		}
 		break;
-	case VIRTIO_CONSOLE_PORT_REMOVE:
-		/*
-		 * Hot unplug the port.  We don't decrement nr_ports
-		 * since we don't want to deal with extra complexities
-		 * of using the lowest-available port id: We can just
-		 * pick up the nr_ports number as the id and not have
-		 * userspace send it to us.  This helps us in two
-		 * ways:
-		 *
-		 * - We don't need to have a 'port_id' field in the
-		 *   config space when a port is hot-added.  This is a
-		 *   good thing as we might queue up multiple hotplug
-		 *   requests issued in our workqueue.
-		 *
-		 * - Another way to deal with this would have been to
-		 *   use a bitmap of the active ports and select the
-		 *   lowest non-active port from that map.  That
-		 *   bloats the already tight config space and we
-		 *   would end up artificially limiting the
-		 *   max. number of ports to sizeof(bitmap).  Right
-		 *   now we can support 2^32 ports (as the port id is
-		 *   stored in a u32 type).
-		 *
-		 */
-		remove_port(port);
-		break;
 	}
 }
 
@@ -1333,7 +1331,6 @@ static const struct file_operations portdev_fops = {
 static int __devinit virtcons_probe(struct virtio_device *vdev)
 {
 	struct ports_device *portdev;
-	u32 i;
 	int err;
 	bool multiport;
 
@@ -1362,29 +1359,15 @@ static int __devinit virtcons_probe(struct virtio_device *vdev)
 	}
 
 	multiport = false;
-	portdev->config.nr_ports = 1;
 	portdev->config.max_nr_ports = 1;
 	if (virtio_has_feature(vdev, VIRTIO_CONSOLE_F_MULTIPORT)) {
 		multiport = true;
 		vdev->features[0] |= 1 << VIRTIO_CONSOLE_F_MULTIPORT;
 
 		vdev->config->get(vdev, offsetof(struct virtio_console_config,
-						 nr_ports),
-				  &portdev->config.nr_ports,
-				  sizeof(portdev->config.nr_ports));
-		vdev->config->get(vdev, offsetof(struct virtio_console_config,
 						 max_nr_ports),
 				  &portdev->config.max_nr_ports,
 				  sizeof(portdev->config.max_nr_ports));
-		if (portdev->config.nr_ports > portdev->config.max_nr_ports) {
-			dev_warn(&vdev->dev,
-				 "More ports (%u) specified than allowed (%u). Will init %u ports.",
-				 portdev->config.nr_ports,
-				 portdev->config.max_nr_ports,
-				 portdev->config.max_nr_ports);
-
-			portdev->config.nr_ports = portdev->config.max_nr_ports;
-		}
 	}
 
 	/* Let the Host know we support multiple ports.*/
@@ -1412,13 +1395,20 @@ static int __devinit virtcons_probe(struct virtio_device *vdev)
 			err = -ENOMEM;
 			goto free_vqs;
 		}
+
 	}
 
-	for (i = 0; i < portdev->config.nr_ports; i++)
-		add_port(portdev, i);
+	/*
+	 * For backward compatibility: if we're running on an older
+	 * host, we always want to create a console port.
+	 */
+	add_port(portdev, 0);
 
 	/* Start using the new console output. */
 	early_put_chars = NULL;
+
+	__send_control_msg(portdev, VIRTIO_CONSOLE_BAD_ID,
+			   VIRTIO_CONSOLE_DEVICE_READY, 1);
 	return 0;
 
 free_vqs:
diff --git a/include/linux/virtio_console.h b/include/linux/virtio_console.h
index ae4f039..a85064d 100644
--- a/include/linux/virtio_console.h
+++ b/include/linux/virtio_console.h
@@ -14,6 +14,8 @@
 #define VIRTIO_CONSOLE_F_SIZE	0	/* Does host provide console size? */
 #define VIRTIO_CONSOLE_F_MULTIPORT 1	/* Does host provide multiple ports? */
 
+#define VIRTIO_CONSOLE_BAD_ID		(~(u32)0)
+
 struct virtio_console_config {
 	/* colums of the screens */
 	__u16 cols;
@@ -21,8 +23,6 @@ struct virtio_console_config {
 	__u16 rows;
 	/* max. number of ports this device can hold */
 	__u32 max_nr_ports;
-	/* number of ports added so far */
-	__u32 nr_ports;
 } __attribute__((packed));
 
 /*
@@ -36,12 +36,14 @@ struct virtio_console_control {
 };
 
 /* Some events for control messages */
-#define VIRTIO_CONSOLE_PORT_READY	0
-#define VIRTIO_CONSOLE_CONSOLE_PORT	1
-#define VIRTIO_CONSOLE_RESIZE		2
-#define VIRTIO_CONSOLE_PORT_OPEN	3
-#define VIRTIO_CONSOLE_PORT_NAME	4
-#define VIRTIO_CONSOLE_PORT_REMOVE	5
+#define VIRTIO_CONSOLE_DEVICE_READY	0
+#define VIRTIO_CONSOLE_PORT_ADD		1
+#define VIRTIO_CONSOLE_PORT_REMOVE	2
+#define VIRTIO_CONSOLE_PORT_READY	3
+#define VIRTIO_CONSOLE_CONSOLE_PORT	4
+#define VIRTIO_CONSOLE_RESIZE		5
+#define VIRTIO_CONSOLE_PORT_OPEN	6
+#define VIRTIO_CONSOLE_PORT_NAME	7
 
 #ifdef __KERNEL__
 int __init virtio_cons_early_init(int (*put_chars)(u32, const char *, int));
-- 
1.6.2.5

[PATCH 6/7] virtio: console: Don't always create a port 0 if using multiport

[Amit Shah]

If we're using multiport, there's no point in always creating a console
port. Create the console port only if the host doesn't support
multiport.

Signed-off-by: Amit Shah <amit.shah@redhat.com>
---
 drivers/char/virtio_console.c |   23 ++++++++---------------
 1 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 8b67ff1..55de0b5 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -1044,14 +1044,8 @@ static void handle_control_message(struct ports_device *portdev,
 	switch (cpkt->event) {
 	case VIRTIO_CONSOLE_PORT_ADD:
 		if (port) {
-			/*
-			 * This can happen for port 0: we have to
-			 * create a console port during probe() as was
-			 * the behaviour before the MULTIPORT feature.
-			 * On a newer host, when the host tells us
-			 * that a port 0 is available, we should just
-			 * say we have the port all set up.
-			 */
+			dev_dbg(&portdev->vdev->dev,
+				"Port %u already added\n", port->id);
 			send_control_msg(port, VIRTIO_CONSOLE_PORT_READY, 1);
 			break;
 		}
@@ -1395,15 +1389,14 @@ static int __devinit virtcons_probe(struct virtio_device *vdev)
 			err = -ENOMEM;
 			goto free_vqs;
 		}
-
+	} else {
+		/*
+		 * If we're running on an older host, we always want
+		 * to create a console port.
+		 */
+		add_port(portdev, 0);
 	}
 
-	/*
-	 * For backward compatibility: if we're running on an older
-	 * host, we always want to create a console port.
-	 */
-	add_port(portdev, 0);
-
 	/* Start using the new console output. */
 	early_put_chars = NULL;
 
-- 
1.6.2.5

[PATCH 7/7] virtio: console: Return -EPIPE if port on the host isn't connected

[Amit Shah]

The virtio-serial ports are like pipes, if there's no reader on the
other end, sending data might get it either ignored or the host might
return '0', which would make guests get -EAGAIN. Since we know the state
of the host port connection, it's appropriate to let the application
know that the other end isn't connected.

Signed-off-by: Amit Shah <amit.shah@redhat.com>
---
 drivers/char/virtio_console.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
index 55de0b5..4562964 100644
--- a/drivers/char/virtio_console.c
+++ b/drivers/char/virtio_console.c
@@ -411,6 +411,9 @@ static ssize_t send_buf(struct port *port, void *in_buf, size_t in_count)
 	ssize_t ret;
 	unsigned int len;
 
+	if (use_multiport(port->portdev) && !port->host_connected)
+		return -EPIPE;
+
 	out_vq = port->out_vq;
 
 	sg_init_one(sg, in_buf, in_count);
-- 
1.6.2.5

Re: [PATCH 7/7] virtio: console: Return -EPIPE if port on the host isn't connected

[Michael S. Tsirkin]

On Tue, Mar 23, 2010 at 02:28:00PM +0530, Amit Shah wrote:
> The virtio-serial ports are like pipes, if there's no reader on the
> other end, sending data might get it either ignored or the host might
> return '0', which would make guests get -EAGAIN. Since we know the state
> of the host port connection, it's appropriate to let the application
> know that the other end isn't connected.
> 
> Signed-off-by: Amit Shah <amit.shah@redhat.com>
> ---
>  drivers/char/virtio_console.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
> index 55de0b5..4562964 100644
> --- a/drivers/char/virtio_console.c
> +++ b/drivers/char/virtio_console.c
> @@ -411,6 +411,9 @@ static ssize_t send_buf(struct port *port, void *in_buf, size_t in_count)
>  	ssize_t ret;
>  	unsigned int len;
>  
> +	if (use_multiport(port->portdev) && !port->host_connected)
> +		return -EPIPE;
> +

Hmm, do applications actually handle this error?

>  	out_vq = port->out_vq;
>  
>  	sg_init_one(sg, in_buf, in_count);
> -- 
> 1.6.2.5

Re: [PATCH 7/7] virtio: console: Return -EPIPE if port on the host isn't connected

[Amit Shah]

On (Tue) Mar 23 2010 [11:00:23], Michael S. Tsirkin wrote:
> On Tue, Mar 23, 2010 at 02:28:00PM +0530, Amit Shah wrote:
> > The virtio-serial ports are like pipes, if there's no reader on the
> > other end, sending data might get it either ignored or the host might
> > return '0', which would make guests get -EAGAIN. Since we know the state
> > of the host port connection, it's appropriate to let the application
> > know that the other end isn't connected.
> > 
> > Signed-off-by: Amit Shah <amit.shah@redhat.com>
> > ---
> >  drivers/char/virtio_console.c |    3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
> > index 55de0b5..4562964 100644
> > --- a/drivers/char/virtio_console.c
> > +++ b/drivers/char/virtio_console.c
> > @@ -411,6 +411,9 @@ static ssize_t send_buf(struct port *port, void *in_buf, size_t in_count)
> >  	ssize_t ret;
> >  	unsigned int len;
> >  
> > +	if (use_multiport(port->portdev) && !port->host_connected)
> > +		return -EPIPE;
> > +
> 
> Hmm, do applications actually handle this error?

Don't know; there aren't any apps yet that use this functionality too.
However, some error has to be indicated to the app otherwise it's just
messy if the app keeps writing and receiving EAGAIN; we just get a tight
loop in this case.

		Amit

Re: [PATCH 7/7] virtio: console: Return -EPIPE if port on the host isn't connected

[Gerd Hoffmann]

On 03/23/10 10:13, Amit Shah wrote:
>>> +	if (use_multiport(port->portdev)&&  !port->host_connected)
>>> +		return -EPIPE;
>>> +
>>
>> Hmm, do applications actually handle this error?
>
> Don't know; there aren't any apps yet that use this functionality too.

Looks sensible to me.

> However, some error has to be indicated to the app otherwise it's just
> messy if the app keeps writing and receiving EAGAIN; we just get a tight
> loop in this case.

With poll support done right (don't signal "writable" when not 
connected) this shouldn't be a issue.  Apps retrying over and over 
without waiting for the filehandle becoming writable are broken by design.

But apps can't disturgish between "ring full" and "host disconnected" 
then.  So think returning -EPIPE here isn't a bad choice.

cheers,
   Gerd

Re: [PATCH 7/7] virtio: console: Return -EPIPE if port on the host isn't connected

[Amit Shah]

On (Tue) Mar 23 2010 [11:46:54], Gerd Hoffmann wrote:
> On 03/23/10 10:13, Amit Shah wrote:
>>>> +	if (use_multiport(port->portdev)&&  !port->host_connected)
>>>> +		return -EPIPE;
>>>> +
>>>
>>> Hmm, do applications actually handle this error?
>>
>> Don't know; there aren't any apps yet that use this functionality too.
>
> Looks sensible to me.
>
>> However, some error has to be indicated to the app otherwise it's just
>> messy if the app keeps writing and receiving EAGAIN; we just get a tight
>> loop in this case.
>
> With poll support done right (don't signal "writable" when not  
> connected) this shouldn't be a issue.  Apps retrying over and over  
> without waiting for the filehandle becoming writable are broken by 
> design.

Yeah; poll returns POLLOUT only when the host connection is open. This
is for apps that write() without consulting poll().

> But apps can't disturgish between "ring full" and "host disconnected"  
> then.  So think returning -EPIPE here isn't a bad choice.

Yeah; that too.

		Amit

Re: [PATCH 7/7] virtio: console: Return -EPIPE if port on the host isn't connected

[Gerd Hoffmann]

On 03/23/10 11:52, Amit Shah wrote:

>> With poll support done right (don't signal "writable" when not
>> connected) this shouldn't be a issue.  Apps retrying over and over
>> without waiting for the filehandle becoming writable are broken by
>> design.
>
> Yeah; poll returns POLLOUT only when the host connection is open. This
> is for apps that write() without consulting poll().

Well, /me just remembers this also depends on the file mode.  Returning 
-EAGAIN instantly is fine for non-blocking file handles.  For file 
handles in blocking mode you would have to block here, waiting for the 
host to connect.

cheers,
   Gerd

Re: [PATCH 7/7] virtio: console: Return -EPIPE if port on the host isn't connected

[Amit Shah]

On (Tue) Mar 23 2010 [11:00:23], Michael S. Tsirkin wrote:
> On Tue, Mar 23, 2010 at 02:28:00PM +0530, Amit Shah wrote:
> > The virtio-serial ports are like pipes, if there's no reader on the
> > other end, sending data might get it either ignored or the host might
> > return '0', which would make guests get -EAGAIN. Since we know the state
> > of the host port connection, it's appropriate to let the application
> > know that the other end isn't connected.
> > 
> > Signed-off-by: Amit Shah <amit.shah@redhat.com>
> > ---
> >  drivers/char/virtio_console.c |    3 +++
> >  1 files changed, 3 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
> > index 55de0b5..4562964 100644
> > --- a/drivers/char/virtio_console.c
> > +++ b/drivers/char/virtio_console.c
> > @@ -411,6 +411,9 @@ static ssize_t send_buf(struct port *port, void *in_buf, size_t in_count)
> >  	ssize_t ret;
> >  	unsigned int len;
> >  
> > +	if (use_multiport(port->portdev) && !port->host_connected)
> > +		return -EPIPE;
> > +
> 
> Hmm, do applications actually handle this error?

As Michael points out on irc, console-handling apps may not handle EPIPE
properly. So I guess the test should be reworked to:

if (!is_console_port(port) && !port->host_connected)
	return -EPIPE;

Also, he points out that write(2) mentions other error messages can be
returned depending on the file type. So we could return -ENOTCONN.

		Amit

Re: [PATCH 7/7] virtio: console: Return -EPIPE if port on the host isn't connected

[Amit Shah]

On (Tue) Mar 23 2010 [12:04:28], Gerd Hoffmann wrote:
> On 03/23/10 11:52, Amit Shah wrote:
>
>>> With poll support done right (don't signal "writable" when not
>>> connected) this shouldn't be a issue.  Apps retrying over and over
>>> without waiting for the filehandle becoming writable are broken by
>>> design.
>>
>> Yeah; poll returns POLLOUT only when the host connection is open. This
>> is for apps that write() without consulting poll().
>
> Well, /me just remembers this also depends on the file mode.  Returning  
> -EAGAIN instantly is fine for non-blocking file handles.  For file  
> handles in blocking mode you would have to block here, waiting for the  
> host to connect.

Ah, right.

I didn't really look at blocking / non-blocking support in write()
because of the cpu_relax(), which will always block the app.

I'll add this.

		Amit

Re: [PATCH 7/7] virtio: console: Return -EPIPE if port on the host isn't connected

[Gerd Hoffmann]

On 03/23/10 12:09, Amit Shah wrote:
> I didn't really look at blocking / non-blocking support in write()
> because of the cpu_relax(), which will always block the app.

Right, the spinning again ...

When we kill this we really must care to implement blocking + 
non-blocking + poll + partial writes correctly.

cheers,
   Gerd

Re: [PATCH 7/7] virtio: console: Return -EPIPE if port on the host isn't connected

[Amit Shah]

On (Tue) Mar 23 2010 [12:15:19], Gerd Hoffmann wrote:
> On 03/23/10 12:09, Amit Shah wrote:
>> I didn't really look at blocking / non-blocking support in write()
>> because of the cpu_relax(), which will always block the app.
>
> Right, the spinning again ...
>
> When we kill this we really must care to implement blocking +  
> non-blocking + poll + partial writes correctly.

Yes; I'm adding blocking/non-blocking right away for the host_connected
condition.

Partial writes, blocking/non-blocking vq operations will have to come
for 2.6.35 at the latest.

		Amit

Re: [PATCH 0/7] virtio: console: Fixes, new flexible way of discovering ports

[Rusty Russell]

On Tue, 23 Mar 2010 07:27:53 pm Amit Shah wrote:
> Hello all,
> 
> This new patchset switches over to using the control queue for port
> discovery so that we can stay in sync with the host for port
> enumeration and also don't use bitmaps to limit us to config space
> sizes.
> 
> This changes the ABI, so it would be better to merge this for 2.6.34
> so that we don't have to worry about released kernels with the older
> ABI.

This looks horribly like development during the merge window.

Sorry,
Rusty.

Re: [PATCH 0/7] virtio: console: Fixes, new flexible way of discovering ports

[Amit Shah]

On (Tue) Mar 30 2010 [15:46:14], Rusty Russell wrote:
> On Tue, 23 Mar 2010 07:27:53 pm Amit Shah wrote:
> > Hello all,
> > 
> > This new patchset switches over to using the control queue for port
> > discovery so that we can stay in sync with the host for port
> > enumeration and also don't use bitmaps to limit us to config space
> > sizes.
> > 
> > This changes the ABI, so it would be better to merge this for 2.6.34
> > so that we don't have to worry about released kernels with the older
> > ABI.
> 
> This looks horribly like development during the merge window.

Yep, let's go ahead with disabling multiport for now and enabling it
later for .35.

Thanks,

		Amit