search for: out_vqs

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

...e(&portdev->ports_lock, flags); - return port; + return vq->vdev_priv; } static bool is_console_port(struct port *port) @@ -1159,6 +1149,8 @@ static int add_port(struct ports_device *portdev, u32 id) port->in_vq = portdev->in_vqs[port->id]; port->out_vq = portdev->out_vqs[port->id]; + port->in_vq->vdev_priv = port; + port->out_vq->vdev_priv = port; port->cdev = cdev_alloc(); if (!port->cdev) { @@ -1872,6 +1864,8 @@ static int virtcons_restore(struct virtio_device *vdev) list_for_each_entry(port, &portdev->ports, list) { port-&g...

...e(&portdev->ports_lock, flags); - return port; + return vq->vdev_priv; } static bool is_console_port(struct port *port) @@ -1159,6 +1149,8 @@ static int add_port(struct ports_device *portdev, u32 id) port->in_vq = portdev->in_vqs[port->id]; port->out_vq = portdev->out_vqs[port->id]; + port->in_vq->vdev_priv = port; + port->out_vq->vdev_priv = port; port->cdev = cdev_alloc(); if (!port->cdev) { @@ -1872,6 +1864,8 @@ static int virtcons_restore(struct virtio_device *vdev) list_for_each_entry(port, &portdev->ports, list) { port-&g...

The get_buf() API sets the second arg to the number of bytes *written* by the other side; in this case it should be zero as these are output buffers. lguest gets this right (obviously kvm's console doesn't), resulting in continual buildup of console writes. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> To: Amit Shah <amit.shah at redhat.com> ---

The get_buf() API sets the second arg to the number of bytes *written* by the other side; in this case it should be zero as these are output buffers. lguest gets this right (obviously kvm's console doesn't), resulting in continual buildup of console writes. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> To: Amit Shah <amit.shah at redhat.com> ---

...+ io_names[vq_num + 1] = "serial-output"; > + err = portdev->vdev->config->find_vqs(portdev->vdev, nr_queues, vqs, > + io_callbacks, > + (const char **)io_names); > + if (err) > + goto free; > + portdev->in_vqs[id] = vqs[vq_num]; > + portdev->out_vqs[id] = vqs[vq_num + 1]; I don't think this approach will work fine for port hot-plug / hot-unplug cases at all. For example, I first start qemu with one port, at id 1. Then I add a port at id 5, then at 2, then at 10. Will that be fine? > + > +free: > + kfree(io_names); > + kfree...

...+ io_names[vq_num + 1] = "serial-output"; > + err = portdev->vdev->config->find_vqs(portdev->vdev, nr_queues, vqs, > + io_callbacks, > + (const char **)io_names); > + if (err) > + goto free; > + portdev->in_vqs[id] = vqs[vq_num]; > + portdev->out_vqs[id] = vqs[vq_num + 1]; I don't think this approach will work fine for port hot-plug / hot-unplug cases at all. For example, I first start qemu with one port, at id 1. Then I add a port at id 5, then at 2, then at 10. Will that be fine? > + > +free: > + kfree(io_names); > + kfree...

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Remove buffers from the out-queue when a port is removed. Rproc_serial communicates with remote processors that may crash and leave buffers in the out-queue. The virtio serial ports may have buffers in the out-queue as well, e.g. for non-blocking ports and the host didn't consume them yet. [Amit: Remove WARN_ON for generic ports

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Remove buffers from the out-queue when a port is removed. Rproc_serial communicates with remote processors that may crash and leave buffers in the out-queue. The virtio serial ports may have buffers in the out-queue as well, e.g. for non-blocking ports and the host didn't consume them yet. [Amit: Remove WARN_ON for generic ports

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add a simple serial connection driver called VIRTIO_ID_RPROC_SERIAL (11) for communicating with a remote processor in an asymmetric multi-processing configuration. This implementation reuses the existing virtio_console implementation, and adds support for DMA allocation of data buffers and disables use of tty console and the virtio

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add a simple serial connection driver called VIRTIO_ID_RPROC_SERIAL (11) for communicating with a remote processor in an asymmetric multi-processing configuration. This implementation reuses the existing virtio_console implementation, and adds support for DMA allocation of data buffers and disables use of tty console and the virtio

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> I thought rebasing rproc_serial to linux-next was going to be trivial. But when starting the merge I realized that I had to refactor the the patches from Masami Hiramatsu. The splice support has the same issue as I faced, with different type of buffers in the out_vq. So I ended up refactoring the splice functionality. The code size

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> I thought rebasing rproc_serial to linux-next was going to be trivial. But when starting the merge I realized that I had to refactor the the patches from Masami Hiramatsu. The splice support has the same issue as I faced, with different type of buffers in the out_vq. So I ended up refactoring the splice functionality. The code size

> + vpmem->vdev = vdev; > + vdev->priv = vpmem; > + err = init_vq(vpmem); > + if (err) { > + dev_err(&vdev->dev, "failed to initialize virtio pmem vq's\n"); > + goto out_err; > + } > + > + virtio_cread(vpmem->vdev, struct virtio_pmem_config, > + start, &vpmem->start); > + virtio_cread(vpmem->vdev, struct

> + vpmem->vdev = vdev; > + vdev->priv = vpmem; > + err = init_vq(vpmem); > + if (err) { > + dev_err(&vdev->dev, "failed to initialize virtio pmem vq's\n"); > + goto out_err; > + } > + > + virtio_cread(vpmem->vdev, struct virtio_pmem_config, > + start, &vpmem->start); > + virtio_cread(vpmem->vdev, struct

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. This patch-set is a rework of the

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. This patch-set is a rework of the

This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. NOTE: These two patches are identical to first two patches of the V8 patch-set, but are rebased to

This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. NOTE: These two patches are identical to first two patches of the V8 patch-set, but are rebased to