From: Rusty Russell <rusty@rustcorp.com.au>
To: sjur.brandeland@stericsson.com, Amit Shah <amit.shah@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
"Linus Walleij" <linus.walleij@linaro.org>,
"Masami Hiramatsu" <masami.hiramatsu.pt@hitachi.com>,
"Ohad Ben-Cohen" <ohad@wizery.com>,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org, sjurbren@gmail.com,
"Sjur Brændeland" <sjur.brandeland@stericsson.com>
Subject: Re: [PATCHv7 4/4] virtio_console: Add support for remoteproc serial
Date: Tue, 23 Oct 2012 12:17:49 +1030 [thread overview]
Message-ID: <878vayhsca.fsf@rustcorp.com.au> (raw)
In-Reply-To: <1350287856-5284-5-git-send-email-sjur.brandeland@stericsson.com>
sjur.brandeland@stericsson.com writes:
> From: Sjur Brændeland <sjur.brandeland@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 control queue.
>
> Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
The free-outside-interrupt issue is usually dealt with by offloading to
a wq, but your variant works (and isn't too ugly).
> + /* dma_free_coherent requires interrupts to be enabled. */
> + if (!can_sleep) {
> + /* queue up dma-buffers to be freed later */
> + spin_lock_irqsave(&dma_bufs_lock, flags);
> + list_add_tail(&buf->list, &pending_free_dma_bufs);
> + spin_unlock_irqrestore(&dma_bufs_lock, flags);
> + return;
> + }
> + dma_free_coherent(buf->dev, buf->size, buf->buf, buf->dma);
> +
> + /* Release device refcnt and allow it to be freed */
> + put_device(buf->dev);
...
> +static void reclaim_dma_bufs(void)
> +{
> + unsigned long flags;
> + struct port_buffer *buf, *tmp;
> + LIST_HEAD(tmp_list);
> +
> + if (list_empty(&pending_free_dma_bufs))
> + return;
> +
> + /* Create a copy of the pending_free_dma_bufs while holding the lock */
> + spin_lock_irqsave(&dma_bufs_lock, flags);
> + list_cut_position(&tmp_list, &pending_free_dma_bufs,
> + pending_free_dma_bufs.prev);
> + spin_unlock_irqrestore(&dma_bufs_lock, flags);
> +
> + /* Release the dma buffers, without irqs enabled */
> + list_for_each_entry_safe(buf, tmp, &tmp_list, list) {
> + list_del(&buf->list);
> + free_buf(buf, true);
> + }
> +}
Looks like this should be an easy noop even if !is_rproc_serial.
> +
> static struct port_buffer *alloc_buf(struct virtqueue *vq, size_t buf_size,
> int pages)
> {
> struct port_buffer *buf;
>
> + if (is_rproc_serial(vq->vdev))
> + reclaim_dma_bufs();
> +
...
> @@ -904,6 +1000,8 @@ static int port_fops_release(struct inode *inode, struct file *filp)
> reclaim_consumed_buffers(port);
> spin_unlock_irq(&port->outvq_lock);
>
> + if (is_rproc_serial(port->portdev->vdev))
> + reclaim_dma_bufs();
So these are redundant.
> @@ -1415,7 +1524,16 @@ static void remove_port_data(struct port *port)
>
> /* Remove buffers we queued up for the Host to send us data in. */
> while ((buf = virtqueue_detach_unused_buf(port->in_vq)))
> - free_buf(buf);
> + free_buf(buf, true);
> +
> + /*
> + * Remove buffers from out queue for rproc-serial. We cannot afford
> + * to leak any DMA mem, so reclaim this memory even if this might be
> + * racy for the remote processor.
> + */
> + if (is_rproc_serial(port->portdev->vdev))
> + while ((buf = virtqueue_detach_unused_buf(port->out_vq)))
> + free_buf(buf, true);
> }
This seems wrong; either this is needed even if !is_rproc_serial(), or
it's not necessary as the out_vq is empty.
Every path I can see has the device reset (in which case the queues
should not be active), or we got a VIRTIO_CONSOLE_PORT_REMOVE event (in
which case, the same).
I think we can have non-blocking writes which could leave buffers in
out_vq: Amit?
> static void __exit fini(void)
> {
> + reclaim_dma_bufs();
Hmm, you didn't protect it here anyway...
Cheers,
Rusty.
next prev parent reply other threads:[~2012-10-23 2:01 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-15 7:57 [PATCHv7 0/4] virtio_console: Add rproc_serial driver sjur.brandeland
2012-10-15 7:57 ` sjur.brandeland
2012-10-15 7:57 ` [PATCHv7 1/4] virtio_console: Free buffer if splice fails sjur.brandeland
2012-10-23 0:12 ` Rusty Russell
2012-10-23 0:12 ` Rusty Russell
2012-10-15 7:57 ` sjur.brandeland
2012-10-15 7:57 ` [PATCHv7 2/4] virtio_console: Use kmalloc instead of kzalloc sjur.brandeland
2012-10-15 7:57 ` sjur.brandeland
2012-10-23 1:36 ` Rusty Russell
2012-10-23 1:36 ` Rusty Russell
2012-10-15 7:57 ` [PATCHv7 3/4] virtio_console: Merge struct buffer_token into struct port_buffer sjur.brandeland
2012-10-15 7:57 ` sjur.brandeland
2012-10-23 0:19 ` Rusty Russell
2012-10-23 0:19 ` Rusty Russell
2012-10-15 7:57 ` [PATCHv7 4/4] virtio_console: Add support for remoteproc serial sjur.brandeland
2012-10-15 7:57 ` sjur.brandeland
2012-10-23 1:47 ` Rusty Russell [this message]
2012-10-28 21:58 ` Sjur Brændeland
2012-10-28 21:58 ` Sjur Brændeland
2012-11-01 7:39 ` Amit Shah
2012-11-01 23:22 ` Rusty Russell
2012-11-01 23:22 ` Rusty Russell
2012-11-02 10:20 ` Amit Shah
2012-11-02 10:20 ` Amit Shah
2012-11-02 10:44 ` Sjur BRENDELAND
2012-11-02 10:44 ` Sjur BRENDELAND
2012-11-07 13:43 ` [PATCH resend] virtio_console: Free buffers from out-queue upon close sjur.brandeland
2012-11-07 13:43 ` sjur.brandeland
2012-11-07 23:58 ` Rusty Russell
2012-11-08 8:59 ` Amit Shah
2012-11-08 8:59 ` Amit Shah
2012-11-08 9:25 ` Sjur Brændeland
2012-11-08 9:25 ` Sjur Brændeland
2012-11-07 23:58 ` Rusty Russell
2012-11-07 14:22 ` sjur.brandeland
2012-11-07 14:22 ` sjur.brandeland
2012-11-01 7:39 ` [PATCHv7 4/4] virtio_console: Add support for remoteproc serial Amit Shah
2012-10-23 1:47 ` Rusty Russell
2012-10-22 13:00 ` [PATCHv7 0/4] virtio_console: Add rproc_serial driver Amit Shah
2012-10-22 13:00 ` Amit Shah
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878vayhsca.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=amit.shah@redhat.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mst@redhat.com \
--cc=ohad@wizery.com \
--cc=sjur.brandeland@stericsson.com \
--cc=sjurbren@gmail.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.