From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 679A5C10F13 for ; Mon, 8 Apr 2019 12:37:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 42C9921473 for ; Mon, 8 Apr 2019 12:37:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726492AbfDHMhu (ORCPT ); Mon, 8 Apr 2019 08:37:50 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:45960 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726387AbfDHMhu (ORCPT ); Mon, 8 Apr 2019 08:37:50 -0400 Received: by mail-qt1-f196.google.com with SMTP id v20so15062940qtv.12 for ; Mon, 08 Apr 2019 05:37:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=CT4LBJnNkSKp6F/tXyjc+IMgXqOXZ7hCnM1QOYMaxVA=; b=p0mGwU7m3UazMqRLkQHmfWsVJXE+dAJKTFf2F8AJjoYgL1WruSKcsPcQ971OzCGwb/ vFKzxjALLHzLtwdNbTGZN1t51weciIYM/C2q26C3M6cff9TVueOQGvRCNhJ8tS1VtnFy jSoiOsdFliUBeR5GgLVndv5575ntmxDMNXYnbseXcHxc2WnY/CX3x20FmuZM9E/nJ8R2 XFsUVjgp7c20ykscgEQQkwXd5sCyRLpOiEZ0gWjuDO5lDBjXh4YHk1BJwSumCUapSji5 fE4a2uPgbdt91fioj0HJNVXuOsgzFtjrDk2qxfoeKC/JvSTCPHMPn/5q/snqaUi9ap/a Htzw== X-Gm-Message-State: APjAAAUBmRDmhqDCy+o7clc/az5kJygYo93tJx9zRhUQ+5Jue3aUNiVd Gf2p6TSeQR3G8GV1k+uHV0+wOQ== X-Google-Smtp-Source: APXvYqzjG12ZvRlaMDhz5R750j/UkUzn0ildgXRHg/olT3iPPXAR07O2p90yHjR6Y2T9e3vC2SSW/g== X-Received: by 2002:aed:3622:: with SMTP id e31mr22763032qtb.97.1554727069166; Mon, 08 Apr 2019 05:37:49 -0700 (PDT) Received: from redhat.com (pool-173-76-246-42.bstnma.fios.verizon.net. [173.76.246.42]) by smtp.gmail.com with ESMTPSA id a20sm16919415qth.88.2019.04.08.05.37.47 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 08 Apr 2019 05:37:48 -0700 (PDT) Date: Mon, 8 Apr 2019 08:37:41 -0400 From: "Michael S. Tsirkin" To: Cornelia Huck Cc: Halil Pasic , kvm@vger.kernel.org, linux-s390@vger.kernel.org, Martin Schwidefsky , Sebastian Ott , virtualization@lists.linux-foundation.org, Christian Borntraeger , Viktor Mihajlovski , Vasily Gorbik , Janosch Frank , Claudio Imbrenda , Farhan Ali , Eric Farman Subject: Re: [RFC PATCH 01/12] virtio/s390: use vring_create_virtqueue Message-ID: <20190408083707-mutt-send-email-mst@kernel.org> References: <20190404231622.52531-1-pasic@linux.ibm.com> <20190404231622.52531-2-pasic@linux.ibm.com> <20190408130128.7859febe.cohuck@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190408130128.7859febe.cohuck@redhat.com> Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, Apr 08, 2019 at 01:01:28PM +0200, Cornelia Huck wrote: > On Fri, 5 Apr 2019 01:16:11 +0200 > Halil Pasic wrote: > > > The commit 2a2d1382fe9d ("virtio: Add improved queue allocation API") > > establishes a new way of allocating virtqueues (as a part of the effort > > that taught DMA to virtio rings). > > > > In the future we will want virtio-ccw to use the DMA API as well. > > > > Let us switch from the legacy method of allocating virtqueues to > > vring_create_virtqueue() as the first step into that direction. > > > > Signed-off-by: Halil Pasic > > --- > > drivers/s390/virtio/virtio_ccw.c | 27 ++++++++------------------- > > 1 file changed, 8 insertions(+), 19 deletions(-) > > > > diff --git a/drivers/s390/virtio/virtio_ccw.c b/drivers/s390/virtio/virtio_ccw.c > > index 74c328321889..edf4afe2d688 100644 > > --- a/drivers/s390/virtio/virtio_ccw.c > > +++ b/drivers/s390/virtio/virtio_ccw.c > > > @@ -516,17 +512,10 @@ static struct virtqueue *virtio_ccw_setup_vq(struct virtio_device *vdev, > > err = info->num; > > goto out_err; > > } > > - size = PAGE_ALIGN(vring_size(info->num, KVM_VIRTIO_CCW_RING_ALIGN)); > > - info->queue = alloc_pages_exact(size, GFP_KERNEL | __GFP_ZERO); > > - if (info->queue == NULL) { > > - dev_warn(&vcdev->cdev->dev, "no queue\n"); > > - err = -ENOMEM; > > - goto out_err; > > - } > > + vq = vring_create_virtqueue(i, info->num, KVM_VIRTIO_CCW_RING_ALIGN, > > + vdev, true, true, ctx, > > This second true means 'may_reduce_num'. Looking at the vring code, it > seems that this parameter is never checked; the code will try to > allocate a smaller queue if it can't get the requested size in any > case... this will probably be a problem for legacy virtio-pci, which > explicitly sets may_reduce_num to false. (I can try to come up with a > patch to fix that.) Yes, pls do. Not too late for a bugfix to go into the current linux. > > + virtio_ccw_kvm_notify, callback, name); > > > > - vq = vring_new_virtqueue(i, info->num, KVM_VIRTIO_CCW_RING_ALIGN, vdev, > > - true, ctx, info->queue, virtio_ccw_kvm_notify, > > - callback, name); > > if (!vq) { > > /* For now, we fail if we can't get the requested size. */ > > dev_warn(&vcdev->cdev->dev, "no vq\n"); > > @@ -534,15 +523,17 @@ static struct virtqueue *virtio_ccw_setup_vq(struct virtio_device *vdev, > > goto out_err; > > } > > > > + > > Extra blank line :) > > > /* Register it with the host. */ > > + queue = virtqueue_get_desc_addr(vq); > > if (vcdev->revision == 0) { > > - info->info_block->l.queue = (__u64)info->queue; > > + info->info_block->l.queue = queue; > > info->info_block->l.align = KVM_VIRTIO_CCW_RING_ALIGN; > > info->info_block->l.index = i; > > info->info_block->l.num = info->num; > > You always fill in the size requested by the host, but the actual size > may be smaller (see above). I don't think that is allowed for revision > 0 (which implies !virtio-1). You probably need to call > vring_create_virtqueue with may_reduce_num=false for revision 0 (and > wait for the generic vring code to be fixed...) > > > ccw->count = sizeof(info->info_block->l); > > } else { > > - info->info_block->s.desc = (__u64)info->queue; > > + info->info_block->s.desc = queue; > > info->info_block->s.index = i; > > info->info_block->s.num = info->num; > > Here, you need to obtain the actual number via > virtqueue_get_vring_size(). > > > info->info_block->s.avail = (__u64)virtqueue_get_avail(vq);