qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anton Kuchin <antonkuchin@yandex-team.ru>
Cc: "Stefan Hajnoczi" <stefanha@redhat.com>,
	"Vladimir Sementsov-Ogievskiy" <vsementsov@yandex-team.ru>,
	qemu-devel@nongnu.org, yc-core@yandex-team.ru,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	"Markus Armbruster" <armbru@redhat.com>,
	"Eduardo Habkost" <eduardo@habkost.net>,
	"Juan Quintela" <quintela@redhat.com>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	virtio-fs@redhat.com, "Eric Blake" <eblake@redhat.com>
Subject: Re: [PATCH v3 1/1] vhost-user-fs: add migration type property
Date: Mon, 6 Mar 2023 16:53:16 -0500	[thread overview]
Message-ID: <20230306165137-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <c85c067f-5bbb-ca5c-a6ba-bae1c356eef1@yandex-team.ru>

On Mon, Mar 06, 2023 at 10:55:29PM +0200, Anton Kuchin wrote:
> On 01/03/2023 22:22, Michael S. Tsirkin wrote:
> > On Wed, Mar 01, 2023 at 09:35:56PM +0200, Anton Kuchin wrote:
> > > I do trust them :)
> > > I have to, otherwise we would need to pack all the properties and
> > > flags of qemu to the migration stream and validate them at
> > > destination or entire migration ends up broken beyond repair if
> > > orchestrators tend to do stupid things and need babysitting.
> > This is not at all a crazy idea. It has some disadvantages
> > too esp around cross version migration, which is why we
> > don't do this yet.
> > 
> 
> Indeed. I know VMMs that chose this path. But as long as
> qemu decided to trust orchestrators I think we'd better
> keep this consistent across the codebase.
> 
> Only ivshmem_pre_load callback bothers to check device
> property and virtio_net_tx_waiting_pre_load checks that
> number of queue pairs doesn't exceed allowed maximum, all
> other *_pre_load functions generally just initialize some
> parts of state that need to be set before stream starts
> loading.

We do validate things by necessity we just try to do
as much as we can table-driver so it's not open-coded
and less visible. We used to have lot more callbacks
nowdays we try to keep it table driven.
But e.g. pci streams RO state and validates that it's the same
on destination.


-- 
MST



  reply	other threads:[~2023-03-06 21:54 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-17 17:00 [PATCH v3 0/1] virtio-fs: implement option for stateless migration Anton Kuchin
2023-02-17 17:00 ` [PATCH v3 1/1] vhost-user-fs: add migration type property Anton Kuchin
2023-02-21 20:45   ` Stefan Hajnoczi
2023-02-22 12:20   ` Vladimir Sementsov-Ogievskiy
2023-02-22 12:43     ` Michael S. Tsirkin
2023-02-22 14:25       ` Anton Kuchin
2023-02-22 15:14         ` Vladimir Sementsov-Ogievskiy
2023-02-22 16:43           ` Michael S. Tsirkin
2023-02-22 17:15             ` Anton Kuchin
2023-02-22 17:30               ` Michael S. Tsirkin
2023-02-22 16:49           ` Anton Kuchin
2023-02-22 16:51             ` Michael S. Tsirkin
2023-02-22 17:05               ` Anton Kuchin
2023-02-22 17:12                 ` Michael S. Tsirkin
2023-02-22 18:25                   ` Anton Kuchin
2023-02-22 20:21                     ` Michael S. Tsirkin
2023-02-22 20:50                       ` Anton Kuchin
2023-03-01 15:40                         ` Michael S. Tsirkin
2023-02-23  7:36                       ` Michael S. Tsirkin
2023-02-23 21:24                         ` Stefan Hajnoczi
2023-02-24  4:14                           ` Anton Kuchin
2023-02-27 10:19                             ` Anton Kuchin
2023-02-24  8:47                           ` Michael S. Tsirkin
2023-02-28 14:30                             ` Anton Kuchin
2023-02-28 14:57                               ` Michael S. Tsirkin
2023-02-28 17:59                                 ` Anton Kuchin
2023-02-28 21:24                                   ` Michael S. Tsirkin
2023-03-01 14:03                                     ` Vladimir Sementsov-Ogievskiy
2023-03-01 14:46                                       ` Michael S. Tsirkin
2023-03-01 15:40                                         ` Anton Kuchin
2023-03-01 15:52                                           ` Michael S. Tsirkin
2023-03-01 16:29                                             ` Anton Kuchin
2023-03-01 17:19                                               ` Michael S. Tsirkin
2023-03-01 19:42                                             ` Anton Kuchin
2023-03-01 15:07                                     ` Anton Kuchin
2023-03-01 15:24                                       ` Michael S. Tsirkin
2023-03-01 16:04                                         ` Anton Kuchin
2023-03-01 17:17                                           ` Michael S. Tsirkin
2023-03-01 19:35                                             ` Anton Kuchin
2023-03-01 20:22                                               ` Michael S. Tsirkin
2023-03-06 20:55                                                 ` Anton Kuchin
2023-03-06 21:53                                                   ` Michael S. Tsirkin [this message]
2023-03-17 18:04                                                     ` Anton Kuchin
2023-03-01 15:33                                   ` Michael S. Tsirkin
2023-03-17 19:02                                     ` Anton Kuchin
2023-02-28 19:18                                 ` Stefan Hajnoczi
2023-02-28 21:29                                   ` Michael S. Tsirkin
2023-02-28 21:54                                     ` Michael S. Tsirkin
2023-02-22 14:21     ` Anton Kuchin
2023-02-22 15:15       ` Vladimir Sementsov-Ogievskiy
2023-02-22 15:20   ` Vladimir Sementsov-Ogievskiy

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=20230306165137-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=antonkuchin@yandex-team.ru \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=virtio-fs@redhat.com \
    --cc=vsementsov@yandex-team.ru \
    --cc=yc-core@yandex-team.ru \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).