From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41087) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUsKv-0005u1-6Z for qemu-devel@nongnu.org; Mon, 09 Mar 2015 03:42:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YUsKs-0008RM-Fy for qemu-devel@nongnu.org; Mon, 09 Mar 2015 03:42:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59495) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YUsKs-0008RH-7w for qemu-devel@nongnu.org; Mon, 09 Mar 2015 03:42:46 -0400 Date: Mon, 09 Mar 2015 15:41:44 +0800 From: Jason Wang Message-Id: <1425886904.29447.3@smtp.corp.redhat.com> In-Reply-To: <20150306135544.6049dac1.cornelia.huck@de.ibm.com> References: <1425534531-6305-1-git-send-email-jasowang@redhat.com> <1425534531-6305-10-git-send-email-jasowang@redhat.com> <20150306135544.6049dac1.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Subject: Re: [Qemu-devel] [PATCH V3 09/14] virtio: introduce vector to virtqueues mapping List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: qemu-devel@nongnu.org, Anthony Liguori , "Michael S. Tsirkin" On Fri, Mar 6, 2015 at 8:55 PM, Cornelia Huck wrote: > On Thu, 5 Mar 2015 13:48:46 +0800 > Jason Wang wrote: > >> Currently we will try to traverse all virtqueues to find a subset >> that >> using a specific vector. This is sub optimal when we will support >> hundreds or even thousands of virtqueues. So this patch introduces a >> method which could be used by transport to get all virtqueues that >> using a same vector. This is done through QLISTs and the number of >> QLISTs was queried through a transport specific method. When guest >> setting vectors, the virtqueue will be linked and helpers for >> traverse >> the list was also introduced. >> >> The first user will be virtio pci which will use this to speed up >> MSI-X masking and unmasking handling. > > Will there be any users beyond virtio-pci, though? Currently not. But if the vector could be shared in another transport, this is still useful. > For virtio-ccw, at > least, "vectors" are an identity mapping of the queue index. I'm not > sure if introducing (memory) overhead for everyone is worth it. I see. Another reason I make it generic is because I believe we try hard to not expose the internals of VirtQueue to transport specific code. > > >> >> Cc: Anthony Liguori >> Cc: Michael S. Tsirkin >> Signed-off-by: Jason Wang >> --- >> hw/virtio/virtio-pci.c | 8 ++++++++ >> hw/virtio/virtio.c | 32 >> ++++++++++++++++++++++++++++++-- >> include/hw/virtio/virtio-bus.h | 1 + >> include/hw/virtio/virtio.h | 3 +++ >> 4 files changed, 42 insertions(+), 2 deletions(-) >> > >> void virtio_queue_set_vector(VirtIODevice *vdev, int n, uint16_t >> vector) >> { >> - if (n < virtio_get_queue_max(vdev)) >> + VirtQueue *vq = &vdev->vq[n]; >> + >> + if (n < virtio_get_queue_max(vdev)) { >> + if (vdev->vq[n].vector != VIRTIO_NO_VECTOR) { >> + QLIST_REMOVE(vq, node); >> + } >> vdev->vq[n].vector = vector; >> + if (vector != VIRTIO_NO_VECTOR) { >> + QLIST_INSERT_HEAD(&vdev->vector_queues[vector], vq, >> node); >> + } >> + } >> } > > Is there any way to remove an entry? Yes, e.g setting the vector to VIRTIO_NO_VECTOR (e.g during reset or driver exit). > E.g., if the guest unassociates > virtqueues. (I just noticed I probably need to use VIRTIO_NO_VECTOR > instead of 0 for that case in ccw.) Yes, I see 0 is used in virtio_ccw_set_vqs() when addr is zero. If there's no special consideration here, need to use VIRITO_NO_VECTOR. > > > Or maybe I'm completely misunderstanding what vectors are doing on > pci :)