From: Chuang Xu <xuchuangxclwt@bytedance.com>
To: Peter Xu <peterx@redhat.com>
Cc: qemu-devel@nongnu.org, dgilbert@redhat.com, quintela@redhat.com,
zhouyibo@bytedance.com, Paolo Bonzini <pbonzini@redhat.com>,
david@redhat.com, philmd@linaro.org, mst@redhat.com
Subject: Re: [RFC v2 2/3] virtio: support delay of checks in virtio_load()
Date: Tue, 13 Dec 2022 04:21:25 -0800 [thread overview]
Message-ID: <CALophutKKqk5nDK99to-eQDK9UDxpYcwWsFeXWRGDZiZSfGSEw@mail.gmail.com> (raw)
In-Reply-To: <Y5eMfZci3AazVOFl@x1n>
[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]
On 2022/12/13 上午4:18, Peter Xu wrote:
On Tue, Dec 13, 2022 at 12:49:41AM +0800, Chuang Xu wrote:
+bool migration_enable_load_check_delay;
I'm just afraid this is still too hacky.
One thing is because this variable itself to be only set at specific phase
during migration to cover that commit(). The other thing is I'm not sure
we can always rely on the commit() being happen 100% - what if there's no
memory layout changes throughout the whole process of vm load? That'll be
skipped if memory_region_update_pending==false as I said.
Yes, you're right. I wanted to set memory_region_update_pending to true at
the beginning of qemu_loadvm_state_main(), but somehow I forgot this detail..😭
So far the best I can come up with is we allow each virtio device to
register a vm state change handler (during virtio_load) to do the rest,
then in the handler it unregisters itself so it only runs once right before
the VM starts. But I'm not sure whether the virtio developers will be
happy with it. Maybe worth a try.
Feel free to have a look at like kvmvapic_vm_state_change() if you think
that idea worth exploring.
That's a good idea!
But I don't think it's necessary to register a new vm state change handler.
Maybe we just need to add a delay_check flag to VirtIODevice and do those
delayed checks in virtio_vmstate_change() when delay_check is true.
Later I'll upload the v3 patches.
Thanks!
[-- Attachment #2: Type: text/html, Size: 2175 bytes --]
next prev parent reply other threads:[~2022-12-13 12:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-12 16:49 [RFC v2 0/3] migration: reduce time of loading non-iterable vmstate Chuang Xu
2022-12-12 16:49 ` [RFC v2 1/3] memory: add depth assert in address_space_to_flatview Chuang Xu
2022-12-12 16:49 ` [RFC v2 2/3] virtio: support delay of checks in virtio_load() Chuang Xu
2022-12-12 20:18 ` Peter Xu
2022-12-13 12:21 ` Chuang Xu [this message]
2022-12-12 16:49 ` [RFC v2 3/3] migration: reduce time of loading non-iterable vmstate Chuang Xu
2022-12-12 20:23 ` [RFC v2 0/3] " Peter Xu
2022-12-13 12:21 ` Chuang Xu
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=CALophutKKqk5nDK99to-eQDK9UDxpYcwWsFeXWRGDZiZSfGSEw@mail.gmail.com \
--to=xuchuangxclwt@bytedance.com \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=zhouyibo@bytedance.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 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).