From: Peter Xu <peterx@redhat.com>
To: Lukas Straub <lukasstraub2@web.de>
Cc: qemu-devel <qemu-devel@nongnu.org>,
"Juan Quintela" <quintela@redhat.com>,
"Leonardo Bras" <leobras@redhat.com>,
"Cédric Le Goater" <clg@redhat.com>,
"Alex Williamson" <alex.williamson@redhat.com>
Subject: Re: [PATCH 1/2] vfio: Don't be a iterable and legacy device at the same time
Date: Thu, 29 Jun 2023 14:59:18 -0400 [thread overview]
Message-ID: <ZJ3UhhX6ttNsDq00@x1n> (raw)
In-Reply-To: <3c45b84bf970d20bfc72865c4de5c33563c2b62d.1687430098.git.lukasstraub2@web.de>
On Thu, Jun 22, 2023 at 01:22:26PM +0200, Lukas Straub wrote:
> Legacy savevm devices only implement save_state() and load_state().
> Iterable devices shouldn't implement save_state() or else they are
> handled both as an iterable and legacy device in the savevm code.
>
> Signed-off-by: Lukas Straub <lukasstraub2@web.de>
> ---
>
> Note: this patch is completely untested.
PS: if you're not confident on the change will always work, better mark as
rfc to show a proposal of such change.
Comparing to the "legacy" vs "modern" migration, IIUC it was about whether
to use vmsd, so it's "save_state()" vs "vmsd" in that regard.
Personally, I don't immediately see a direct conflict / issue with device
providing both save_state() and save_setup(). It means the device declares
both (1) iterable data, and (2) non-iterable data (which can be either vmsd
or save_state()).
I do think vmsd is still preferred here for (2), e.g., I quickly looked at
vmstate_vfio_pci_config which seems fine to be implemented as a vmsd, with
a post_load() perhaps. But that's another story. It just all looks still
fine.
Do we get any benefit from having that restriction?
--
Peter Xu
prev parent reply other threads:[~2023-06-29 19:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-22 11:22 [PATCH 1/2] vfio: Don't be a iterable and legacy device at the same time Lukas Straub
2023-06-22 11:22 ` [PATCH 2/2] savevm: Disallow devices being legacy and iterable " Lukas Straub
2023-06-29 18:59 ` Peter Xu [this message]
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=ZJ3UhhX6ttNsDq00@x1n \
--to=peterx@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=clg@redhat.com \
--cc=leobras@redhat.com \
--cc=lukasstraub2@web.de \
--cc=qemu-devel@nongnu.org \
--cc=quintela@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.