All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Hanna Czenczek <hreitz@redhat.com>
Cc: "Stefan Hajnoczi" <stefanha@gmail.com>,
	"open list:virtiofs" <virtio-fs@redhat.com>,
	"Eugenio Pérez" <eperezma@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Michael S . Tsirkin" <mst@redhat.com>
Subject: Re: [Virtio-fs] [PATCH v3 0/5] vhost-user: Back-end state migration
Date: Wed, 27 Sep 2023 16:19:22 -0400	[thread overview]
Message-ID: <20230927201922.GB529043@fedora> (raw)
In-Reply-To: <07282c72-7a83-70c5-395d-454281663eb1@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]

On Wed, Sep 27, 2023 at 10:32:14AM +0200, Hanna Czenczek wrote:
> On 26.09.23 22:10, Stefan Hajnoczi wrote:
> > Hi Hanna,
> > I was thinking about how this could work without SUSPEND/RESUME. What
> > do you think of the following?
> > 
> > 1. The front-end sends VHOST_USER_RESET_DEVICE (or
> > VHOST_USER_RESET_OWNER, when necessary) when the guest driver resets
> > the device but not on vhost_dev_start()/vhost_dev_stop().
> 
> This is half the work of SUSPEND/RESUME.  It isn’t easy to do.

I sent a patch series to bring VHOST_USER_RESET_DEVICE to all vhost-user
devices:
https://lore.kernel.org/qemu-devel/20230927192737.528280-1-stefanha@redhat.com/T/#t

> 
> > 2. Suspend the device when all virtqueues are stopped via
> > VHOST_USER_GET_VRING_BASE. Resume the device after at least one
> > virtqueue is started and enabled.
> > 3. Ignore VHOST_USER_SET_STATUS.
> > 
> > Reset would work. The device would suspend and resume without losing
> > state. Existing vhost-user backends already behave like this in
> > practice (they often don't implement RESET_DEVICE).
> 
> I don’t understand the point, though.  Today, reset in practice is a no-op
> anyway, precisely because we only send SET_STATUS 0, don’t fall back to
> RESET_OWNER/RESET_DEVICE, and no back-end implements SET_STATUS 0 as a
> reset.  By sending RESET_* in case of a guest-initiated reset and nothing in
> case of stop/cont, we effectively don’t change anything about the latter
> (which is what SUSPEND/RESUME would be for), but only fix the former case. 
> While I agree that it’s wrong that we don’t really reset the back-end in
> case of a guest-initiated reset, this is the first time in this whole
> discussion that that part has been presented as a problem that needs fixing
> now.
> 
> So the proposal effectively changes nothing for the vhost_dev_stop()/start()
> case where we’d want to make use of SUSPEND/RESUME, but only for the case
> where we would not use it.

We discussed this on a call today. 2 & 3 are additions to the spec that
Hanna has agreed to work on.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2023-09-27 20:19 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-15 10:25 [Virtio-fs] [PATCH v3 0/5] vhost-user: Back-end state migration Hanna Czenczek
2023-09-15 10:25 ` Hanna Czenczek
2023-09-15 10:25 ` [Virtio-fs] [PATCH v3 1/5] vhost-user.rst: Migrating back-end-internal state Hanna Czenczek
2023-09-15 10:25   ` Hanna Czenczek
2023-09-25 19:04   ` [Virtio-fs] " Stefan Hajnoczi
2023-09-25 19:04     ` Stefan Hajnoczi
2023-09-15 10:25 ` [Virtio-fs] [PATCH v3 2/5] vhost-user.rst: Clarify enabling/disabling vrings Hanna Czenczek
2023-09-15 10:25   ` Hanna Czenczek
2023-09-25 19:15   ` [Virtio-fs] " Stefan Hajnoczi
2023-09-25 19:15     ` Stefan Hajnoczi
2023-09-26 13:54     ` [Virtio-fs] " Hanna Czenczek
2023-09-26 13:54       ` Hanna Czenczek
2023-09-26 19:30       ` [Virtio-fs] " Stefan Hajnoczi
2023-09-26 19:30         ` Stefan Hajnoczi
2023-09-15 10:25 ` [Virtio-fs] [PATCH v3 3/5] vhost-user: Interface for migration state transfer Hanna Czenczek
2023-09-15 10:25   ` Hanna Czenczek
2023-09-25 20:18   ` [Virtio-fs] " Stefan Hajnoczi
2023-09-25 20:18     ` Stefan Hajnoczi
2023-09-15 10:25 ` [Virtio-fs] [PATCH v3 4/5] vhost: Add high-level state save/load functions Hanna Czenczek
2023-09-15 10:25   ` Hanna Czenczek
2023-09-25 20:23   ` [Virtio-fs] " Stefan Hajnoczi
2023-09-25 20:23     ` Stefan Hajnoczi
2023-09-15 10:25 ` [Virtio-fs] [PATCH v3 5/5] vhost-user-fs: Implement internal migration Hanna Czenczek
2023-09-15 10:25   ` Hanna Czenczek
2023-09-25 20:26   ` [Virtio-fs] " Stefan Hajnoczi
2023-09-25 20:26     ` Stefan Hajnoczi
2023-09-25 20:48 ` [Virtio-fs] [PATCH v3 0/5] vhost-user: Back-end state migration Stefan Hajnoczi
2023-09-25 20:48   ` Stefan Hajnoczi
2023-09-26 13:32   ` [Virtio-fs] " Hanna Czenczek
2023-09-26 19:20     ` Stefan Hajnoczi
2023-09-26 20:10       ` Stefan Hajnoczi
2023-09-27  8:32         ` Hanna Czenczek
2023-09-27 20:19           ` Stefan Hajnoczi [this message]
2023-09-27  8:13       ` Hanna Czenczek

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=20230927201922.GB529043@fedora \
    --to=stefanha@redhat.com \
    --cc=eperezma@redhat.com \
    --cc=hreitz@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=virtio-fs@redhat.com \
    /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.