Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp1460540ybb; Sun, 29 Mar 2020 05:22:45 -0700 (PDT) X-Google-Smtp-Source: ADFU+vs0DoL4pJQc53Y5ZJpWFEXKQF+MSdZUy4O3j8Qo/9m1p02xba/g3B9qlyOQr366VjZIxr23 X-Received: by 2002:a05:6830:239b:: with SMTP id l27mr5722979ots.278.1585484565582; Sun, 29 Mar 2020 05:22:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585484565; cv=none; d=google.com; s=arc-20160816; b=AjtzBfHtMbvY12be92NoB6M5TWwMb8MqiIp4yKNjRLvuALe+3FzBES9hUEUcjyXw19 BEiQgYGasoC/9LnVOKr+gB5z4UEH44+9WOc2uvILu3gqxkaA76M2kV8pd65+QLVldLse vdOi0YsyrPNoInN+E0EWH7d9ZMFOVHUg+6QAlKWDqU8pWjBauWKRummqdzM5rXTraD1b swH/2rY2PAoEbmvB8VDH0E8vxhqwS3QgFK7/X0adh3U8v/JfyW3F2OPp4ZynB4epEI/3 JD+7jF13vZexwHbejVC+tH0KNm7wqmunBGlgmu2DWHYnC41w2O1+kCPemEMlUJZxBTSV 32UA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=JV+swSpDvLiRyfF8zduIYF+N/77uMAWPzm2YG1hsv6E=; b=E/9ptZtX1gn1LSMEp1lWs2rTTyv8XO1CXqhmusfC7NpDYkAczaqLRzOZrgdS+UdceR 31f82Mhg/DLB3tiyPu7+Gyh+WdAV6cgj23IyZukRtOOQP+Kp33g0aEsDLwwfiPrgazwl 4u2DEIWCEwAoH1l6BP3WohjRfvMF6gumqzPVDcJuOaoLWFKa+r2DnnZE6UfjAVJlnsio Fu6l6wAAFihLHSHRAPolwOsJZc7XJdo/VNJRoTo61bFW4H0tNcn4mW3rJMKsFtzVN0tU Eb9/pN3sgVtzQeTZ9LQEZPcDv58XYTbpJCbE2CSpQVK/F1zPmV4z1EcezL82N50pdxvX TvRw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=a2lGXucn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h66si2755004oif.53.2020.03.29.05.22.32; Sun, 29 Mar 2020 05:22:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=a2lGXucn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728105AbgC2MUi (ORCPT + 99 others); Sun, 29 Mar 2020 08:20:38 -0400 Received: from us-smtp-delivery-74.mimecast.com ([63.128.21.74]:35722 "EHLO us-smtp-delivery-74.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727875AbgC2MUi (ORCPT ); Sun, 29 Mar 2020 08:20:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585484436; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JV+swSpDvLiRyfF8zduIYF+N/77uMAWPzm2YG1hsv6E=; b=a2lGXucnr0oYXe/l1KoX6tzXbtnoB/ZFJnr4tTK1ALU2MJ7JwsCTDFk8AjMLYuXgseW+rl PygIBWN7fUwuaLIY+3eelsoB2lt/JOzBRFYv/Wif5nK8M79YX9b2KFZ7ctHV0jchl7GcxY rmvlQKp8RXB0GlqsKE/EDRRDwaVpFw4= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-190-kIzB4iU6PN2FThZxbqnCvA-1; Sun, 29 Mar 2020 08:20:32 -0400 X-MC-Unique: kIzB4iU6PN2FThZxbqnCvA-1 Received: by mail-qt1-f200.google.com with SMTP id d26so5094467qtb.18 for ; Sun, 29 Mar 2020 05:20:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JV+swSpDvLiRyfF8zduIYF+N/77uMAWPzm2YG1hsv6E=; b=mvnDlws0yuKJzDgs3zGddX0u824AihObaXX2WTYNA6uyI1qs8sORPLzwbSMpSpENWF hRBimYqLZTkxriETLxrAUEhJqyKD/fplUa7ME27bmXrMlEBKV9BBIorp02PLDR8cKToo wJjU/WQGoItP+D0oSs3AUhdnv+I8FNkiDiP0WRk9e2EQZvwj6BGWjSV59CEfjdl0Sv9D 7of5sjuHHgjaV8JwS+bby+pTAJsgflJTdTorxon3WiHsy6WP6GJctwdEbp+7ouSSDBq8 WBEYo07nhmiK9tx3FtwoKL0a8X/H9+zF1sKEYhgIhPMVi3iBABozYeZY1GWzpRkgE/r7 vvPw== X-Gm-Message-State: ANhLgQ1+vTNEpmr6xjhyfppQdhgeUjluJ74eIvmnsX0fmO37E2RhO9kf bBzHu53HeOls4+6yt/3dTp8EbO6x8K9/8glGnFDzZWSiL4HdLeIX2FP5SJQy5ZcYHZDeJHerAz3 w/2YTDEw4lUD98t3eVent69ABJJqxb+8JuoiFZE4P X-Received: by 2002:a37:648:: with SMTP id 69mr7654539qkg.353.1585484432325; Sun, 29 Mar 2020 05:20:32 -0700 (PDT) X-Received: by 2002:a37:648:: with SMTP id 69mr7654519qkg.353.1585484432049; Sun, 29 Mar 2020 05:20:32 -0700 (PDT) MIME-Version: 1.0 References: <20200329113359.30960-1-eperezma@redhat.com> <20200329074023-mutt-send-email-mst@kernel.org> In-Reply-To: <20200329074023-mutt-send-email-mst@kernel.org> From: Eugenio Perez Martin Date: Sun, 29 Mar 2020 14:19:55 +0200 Message-ID: Subject: Re: [PATCH 0/6] vhost: Reset batched descriptors on SET_VRING_BASE call To: "Michael S. Tsirkin" Cc: "virtualization@lists.linux-foundation.org" , Halil Pasic , Stephen Rothwell , Linux Next Mailing List , kvm list , Cornelia Huck , Christian Borntraeger , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Mar 29, 2020 at 1:49 PM Michael S. Tsirkin wrote: > > On Sun, Mar 29, 2020 at 01:33:53PM +0200, Eugenio P=C3=A9rez wrote: > > Vhost did not reset properly the batched descriptors on SET_VRING_BASE = event. Because of that, is possible to return an invalid descriptor to the = guest. > > This series ammend this, and creates a test to assert correct behavior.= To do that, they need to expose a new function in virtio_ring, virtqueue_r= eset_free_head. Not sure if this can be avoided. > > Question: why not reset the batch when private_data changes? > At the moment both net and scsi poke at private data directly, > if they do this through a wrapper we can use that to > 1. check that vq mutex is taken properly > 2. reset batching > > This seems like a slightly better API > I didn't do that way because qemu could just SET_BACKEND to -1 and SET_BACKEND to the same one, with no call to SET_VRING. In this case, I think that qemu should not change the descriptors already pushed. I do agree with the interface to modify private_data properly (regarding the mutex). However, I can see how your proposal is safer, so we don't even need to check if private_data is !=3D NULL when we have descriptors in the batch_descs array. Also, this ioctls should not be in the hot path, so we can change to that mode anyway. > > > > Also, change from https://lkml.org/lkml/2020/3/27/108 is not included, = that avoids to update a variable in a loop where it can be updated once. > > > > This is meant to be applied on top of eccb852f1fe6bede630e2e4f1a121a81e= 34354ab in git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git, and some = commits should be squashed with that series. > > Thanks a lot! I'll apply this for now so Christian can start testing, > but I'd like the comment above addressed before I push this to Linus. > > > Eugenio P=C3=A9rez (6): > > tools/virtio: Add --batch option > > tools/virtio: Add --batch=3Drandom option > > tools/virtio: Add --reset=3Drandom > > tools/virtio: Make --reset reset ring idx > > vhost: Delete virtqueue batch_descs member > > fixup! vhost: batching fetches > > > > drivers/vhost/test.c | 57 ++++++++++++++++ > > drivers/vhost/test.h | 1 + > > drivers/vhost/vhost.c | 12 +++- > > drivers/vhost/vhost.h | 1 - > > drivers/virtio/virtio_ring.c | 18 +++++ > > include/linux/virtio.h | 2 + > > tools/virtio/linux/virtio.h | 2 + > > tools/virtio/virtio_test.c | 123 +++++++++++++++++++++++++++++++---- > > 8 files changed, 201 insertions(+), 15 deletions(-) > > > > -- > > 2.18.1 >