[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH V4 06/19] virtio-ccw: using VIRTIO_NO_VECTOR ins
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [PATCH V4 06/19] virtio-ccw: using VIRTIO_NO_VECTOR instead of 0 for invalid virtqueue |
Date: |
Sat, 21 Mar 2015 19:27:49 +0100 |
On Fri, Mar 20, 2015 at 08:39:24AM +0100, Cornelia Huck wrote:
> On Wed, 18 Mar 2015 14:08:56 +0100
> "Michael S. Tsirkin" <address@hidden> wrote:
>
> > On Wed, Mar 18, 2015 at 05:34:56PM +0800, Jason Wang wrote:
> > > There's no need to use vector 0 for invalid virtqueue. So this patch
> > > changes to use VIRTIO_NO_VECTOR instead.
> > >
> > > Cc: Michael S. Tsirkin <address@hidden>
> > > Cc: Cornelia Huck <address@hidden>
> > > CC: Christian Borntraeger <address@hidden>
> > > Cc: Richard Henderson <address@hidden>
> > > Cc: Alexander Graf <address@hidden>
> > > Signed-off-by: Jason Wang <address@hidden>
> >
> > I don't know what does this actually do.
> > Cornelia?
>
> I actually have the same patch somewhere in my queue. The point here is
> that 0 is plain wrong (it's a valid queue), while VIRTIO_NO_VECTOR is
> most certainly no valid queue.
>
> >
> > > ---
> > > hw/s390x/virtio-ccw.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
> > > index 130535c..c8b87aa 100644
> > > --- a/hw/s390x/virtio-ccw.c
> > > +++ b/hw/s390x/virtio-ccw.c
> > > @@ -281,7 +281,7 @@ static int virtio_ccw_set_vqs(SubchDev *sch, uint64_t
> > > addr, uint32_t align,
> > >
> > > virtio_queue_set_addr(vdev, index, addr);
> > > if (!addr) {
> > > - virtio_queue_set_vector(vdev, index, 0);
> > > + virtio_queue_set_vector(vdev, index, VIRTIO_NO_VECTOR);
> > > } else {
> > > /* Fail if we don't have a big enough queue. */
> > > /* TODO: Add interface to handle vring.num changing */
> >
> > Right below this, we have
> > /* tell notify handler in case of config change */
> > vdev->config_vector = VIRTIO_PCI_QUEUE_MAX;
> >
> > which also does not seem to make sense.
>
> Basically we have:
>
> - at most 64 virtqueues with their own indicators (always 64 indicator
> bits when using classic I/O interrupts, up to 64 indicator bits when
> using adapter interrupts)
> - another indicator bit for configuration changes (bit 0 of the
> secondary indicator bits)
>
> That way, the configuration change indicator is always one bit behind
> the last possible queue indicator.
But VIRTIO_PCI_QUEUE_MAX only makes sense as a VQ number.
Why does it make sense as a vector number?
Jason's patches actually change VIRTIO_PCI_QUEUE_MAX
so we need to figure our what to do for this code.
> >
> > These changes need some testing though.
>
> My identical patch seemed to work for me.
- [Qemu-devel] [PATCH V4 00/19] Support more virtio queues, Jason Wang, 2015/03/18
- [Qemu-devel] [PATCH V4 01/19] pc: add 2.4 machine types, Jason Wang, 2015/03/18
- [Qemu-devel] [PATCH V4 02/19] spapr: add machine type specific instance init function, Jason Wang, 2015/03/18
- [Qemu-devel] [PATCH V4 04/19] monitor: replace the magic number 255 with MAX_QUEUE_NUM, Jason Wang, 2015/03/18
- [Qemu-devel] [PATCH V4 03/19] ppc: spapr: add 2.4 machine type, Jason Wang, 2015/03/18
- [Qemu-devel] [PATCH V4 06/19] virtio-ccw: using VIRTIO_NO_VECTOR instead of 0 for invalid virtqueue, Jason Wang, 2015/03/18
[Qemu-devel] [PATCH V4 05/19] monitor: check return value of qemu_find_net_clients_except(), Jason Wang, 2015/03/18
[Qemu-devel] [PATCH V4 08/19] virtio-net: fix the upper bound when trying to delete queues, Jason Wang, 2015/03/18
[Qemu-devel] [PATCH V4 07/19] virtio-net: validate backend queue numbers against bus limitation, Jason Wang, 2015/03/18
[Qemu-devel] [PATCH V4 10/19] virtio-ccw: introduce ccw specific queue limit, Jason Wang, 2015/03/18