From: Zang Hongyong <zanghongyong@huawei.com>
To: Amit Shah <amit.shah@redhat.com>
Cc: aliguori@us.ibm.com, kvm@vger.kernel.org, wusongwei@huawei.com,
hanweidong@huawei.com,
Virtualization List <virtualization@lists.linux-foundation.org>,
xiaowei.yang@huawei.com, jiangningyu@huawei.com
Subject: Re: [PATCH 2/2] virtio-serial: setup_port_vq when adding port
Date: Wed, 01 Feb 2012 17:32:42 +0800 [thread overview]
Message-ID: <4F2906BA.9040000@huawei.com> (raw)
In-Reply-To: <20120201081257.GD24943@amit.redhat.com>
On 2012/2/1,星期三 16:12, Amit Shah wrote:
> Hi,
>
> Sorry for the late reply.
>
> On (Thu) 12 Jan 2012 [09:20:07], zanghongyong@huawei.com wrote:
>> From: Hongyong Zang<zanghongyong@huawei.com>
>>
>> Add setup_port_vq(). Create the io ports' vqs when add_port.
> Can you describe the changes in more detail, please?
The motivation of this patch is as follows. When we use virtio-serial
for communication between guest and host, we usually use only a few
ports (for example 1 or 2 ports), so there's no need to create max ports
when build a virtio-serial. The patch does the port hot-plug thing without
port hot-unplug.
>
>> Signed-off-by: Hongyong Zang<zanghongyong@huawei.com>
>> ---
>> drivers/char/virtio_console.c | 65 ++++++++++++++++++++++++++++++++++++++--
>> 1 files changed, 61 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
>> index 8e3c46d..2e5187e 100644
>> --- a/drivers/char/virtio_console.c
>> +++ b/drivers/char/virtio_console.c
>> @@ -1132,6 +1132,55 @@ static void send_sigio_to_port(struct port *port)
>> kill_fasync(&port->async_queue, SIGIO, POLL_OUT);
>> }
>>
>> +static void in_intr(struct virtqueue *vq);
>> +static void out_intr(struct virtqueue *vq);
>> +
>> +static int setup_port_vq(struct ports_device *portdev, u32 id)
>> +{
>> + int err, vq_num;
>> + vq_callback_t **io_callbacks;
>> + char **io_names;
>> + struct virtqueue **vqs;
>> + u32 i,j,nr_ports,nr_queues;
>> +
>> + err = 0;
>> + vq_num = (id + 1) * 2;
>> + nr_ports = portdev->config.max_nr_ports;
>> + nr_queues = use_multiport(portdev) ? (nr_ports + 1) * 2 : 2;
>> +
>> + vqs = kmalloc(nr_queues * sizeof(struct virtqueue *), GFP_KERNEL);
>> + io_callbacks = kmalloc(nr_queues * sizeof(vq_callback_t *), GFP_KERNEL);
>> + io_names = kmalloc(nr_queues * sizeof(char *), GFP_KERNEL);
>> + if (!vqs || !io_callbacks || !io_names) {
>> + err = -ENOMEM;
>> + goto free;
>> + }
>> +
>> + for (i = 0, j = 0; i<= nr_ports; i++) {
>> + io_callbacks[j] = in_intr;
>> + io_callbacks[j + 1] = out_intr;
>> + io_names[j] = NULL;
>> + io_names[j + 1] = NULL;
>> + j += 2;
>> + }
>> + io_names[vq_num] = "serial-input";
>> + 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?
yes.
In this case, the virtio-serial will create id 1's queue when probe the
device. Then, add port id 5, it will create the id 5's queue and the queues
of id 2-4 still be null.
we find the right ioport by vq_num, and only the io_name[vq_num] and
io_name[vq_num+1] are not null. So after portdev->vdev->config->find_vqs(),
the id 5's queues are created(see the changes in virtio-pci), the others
are
still null.
>
>> +
>> +free:
>> + kfree(io_names);
>> + kfree(io_callbacks);
>> + kfree(vqs);
>> +
>> + return err;
>> +}
>> +
>> static int add_port(struct ports_device *portdev, u32 id)
>> {
>> char debugfs_name[16];
>> @@ -1163,6 +1212,14 @@ static int add_port(struct ports_device *portdev, u32 id)
>>
>> port->outvq_full = false;
>>
>> + if (!portdev->in_vqs[port->id]&& !portdev->out_vqs[port->id]) {
>> + spin_lock(&portdev->ports_lock);
>> + err = setup_port_vq(portdev, port->id);
>> + spin_unlock(&portdev->ports_lock);
>> + if (err)
>> + goto free_port;
>> + }
>> +
>> port->in_vq = portdev->in_vqs[port->id];
>> port->out_vq = portdev->out_vqs[port->id];
>>
>> @@ -1614,8 +1671,8 @@ static int init_vqs(struct ports_device *portdev)
>> j += 2;
>> io_callbacks[j] = in_intr;
>> io_callbacks[j + 1] = out_intr;
>> - io_names[j] = "input";
>> - io_names[j + 1] = "output";
>> + io_names[j] = NULL;
>> + io_names[j + 1] = NULL;
>> }
>> }
>> /* Find the queues. */
>> @@ -1635,8 +1692,8 @@ static int init_vqs(struct ports_device *portdev)
>>
>> for (i = 1; i< nr_ports; i++) {
>> j += 2;
>> - portdev->in_vqs[i] = vqs[j];
>> - portdev->out_vqs[i] = vqs[j + 1];
>> + portdev->in_vqs[i] = NULL;
>> + portdev->out_vqs[i] = NULL;
>> }
>> }
>> kfree(io_names);
> So a queue once created will not be removed unless the module is
> removed or the device is removed. That seems reasonable, port
> hot-unplug will keep queues around, as is the case now.
As we use the virtio-serial with only a few io-ports, the maxport queues
may
waste more memory. So we try to create queues when port hot-plug, as for
port hot-unplug there's no change.
>
> Amit
>
> .
>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2012-02-01 9:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-12 1:20 [PATCH 0/2] virtio-serial: set up vqs on demand zanghongyong
2012-01-12 1:20 ` [PATCH 1/2] virtio-pci: add setup_vqs flag in vp_try_to_find_vqs zanghongyong
2012-02-01 8:14 ` Amit Shah
2012-02-01 9:54 ` Michael S. Tsirkin
2012-02-03 3:56 ` Rusty Russell
2012-01-12 1:20 ` [PATCH 2/2] virtio-serial: setup_port_vq when adding port zanghongyong
2012-02-01 8:12 ` Amit Shah
2012-02-01 9:32 ` Zang Hongyong [this message]
2012-02-01 9:40 ` [PATCH 0/2] virtio-serial: set up vqs on demand Michael S. Tsirkin
2013-04-08 7:51 ` 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=4F2906BA.9040000@huawei.com \
--to=zanghongyong@huawei.com \
--cc=aliguori@us.ibm.com \
--cc=amit.shah@redhat.com \
--cc=hanweidong@huawei.com \
--cc=jiangningyu@huawei.com \
--cc=kvm@vger.kernel.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=wusongwei@huawei.com \
--cc=xiaowei.yang@huawei.com \
/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.