From: "Michael S. Tsirkin" <mst@redhat.com>
To: Eugenio Perez Martin <eperezma@redhat.com>
Cc: "virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
Halil Pasic <pasic@linux.ibm.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
kvm list <kvm@vger.kernel.org>, Cornelia Huck <cohuck@redhat.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/6] vhost: Reset batched descriptors on SET_VRING_BASE call
Date: Sun, 29 Mar 2020 08:25:05 -0400 [thread overview]
Message-ID: <20200329082055-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <CAJaqyWdO8CHuWFJv+TRgYJ7a3Cb06Ln3prnQZs69L1PPw4Rj1Q@mail.gmail.com>
On Sun, Mar 29, 2020 at 02:19:55PM +0200, Eugenio Perez Martin wrote:
> On Sun, Mar 29, 2020 at 1:49 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Sun, Mar 29, 2020 at 01:33:53PM +0200, Eugenio Pérez 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_reset_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.
Well dropping the batch is always safe, batch is an optimization.
> 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 != 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 eccb852f1fe6bede630e2e4f1a121a81e34354ab 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érez (6):
> > > tools/virtio: Add --batch option
> > > tools/virtio: Add --batch=random option
> > > tools/virtio: Add --reset=random
> > > 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
> >
next prev parent reply other threads:[~2020-03-29 12:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-29 11:33 [PATCH 0/6] vhost: Reset batched descriptors on SET_VRING_BASE call Eugenio Pérez
2020-03-29 11:33 ` [PATCH 1/6] tools/virtio: Add --batch option Eugenio Pérez
2020-03-29 11:33 ` [PATCH 2/6] tools/virtio: Add --batch=random option Eugenio Pérez
2020-03-29 11:33 ` [PATCH 3/6] tools/virtio: Add --reset=random Eugenio Pérez
2020-03-29 11:33 ` [PATCH 4/6] tools/virtio: Make --reset reset ring idx Eugenio Pérez
2020-03-29 12:36 ` Michael S. Tsirkin
2020-03-29 11:33 ` [PATCH 5/6] vhost: Delete virtqueue batch_descs member Eugenio Pérez
2020-03-29 11:33 ` [PATCH 6/6] fixup! vhost: batching fetches Eugenio Pérez
2020-03-29 11:49 ` [PATCH 0/6] vhost: Reset batched descriptors on SET_VRING_BASE call Michael S. Tsirkin
2020-03-29 12:19 ` Eugenio Perez Martin
2020-03-29 12:25 ` Michael S. Tsirkin [this message]
2020-03-30 7:13 ` Christian Borntraeger
2020-03-30 7:18 ` Eugenio Perez Martin
2020-03-30 7:34 ` Christian Borntraeger
2020-03-30 9:15 ` Eugenio Perez Martin
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=20200329082055-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=eperezma@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=pasic@linux.ibm.com \
--cc=sfr@canb.auug.org.au \
--cc=virtualization@lists.linux-foundation.org \
/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.