From: Peter Xu <peterx@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Tian Kevin <kevin.tian@intel.com>,
qemu-devel@nongnu.org, Juan Quintela <quintela@redhat.com>
Subject: Re: [PATCH RFC 0/4] vl: Sync dirty bitmap when system resets
Date: Sat, 23 May 2020 18:49:32 -0400 [thread overview]
Message-ID: <20200523224932.GA939059@xz-x1> (raw)
In-Reply-To: <20200502210423.GB6299@xz-x1>
On Sat, May 02, 2020 at 05:04:23PM -0400, Peter Xu wrote:
> Paolo,
>
> Do you have any opinion on this series? Or more generally comments on what's
> your preference to fix the known dirty sync issue with memslot removal would be
> welcomed too. For my own opinion, I prefer the approach with this series so we
> won't need to touch the kernel at all, and it also paves the way for dirty
> ring. In all cases, I do think collecting dirty bit of a removing slot is
> slightly awkward already.
>
> Dave has valid conerns about other cases besides reboot where we might still
> want to keep the dirty bits, on either (1) during BIOS/... boots, or (2) guest
> unmaps of device mmio regions that were backed up by RAM. I can continue to
> look into theses, however before that I'd appreciate to know whether the
> direction is correct and acceptable.
>
> IMHO the worst case of a series like this could be that we got regression on
> dirty bit loss, but then we can simply revert the last patch to verify or fix
> it (or we can fix the missing case instead).
Hmm... I didn't find a good and clean way to cover what Dave has mentioned.
Everything would be either ugly or even uglier. Sad.
Since I didn't get any feedback either on this for some time (or the rest of
the discussion threads or proposals I opened), I think it's time to move on...
I start to feel unwise to continue have the two kvm dirty ring series blocked
due to this extremely corner case of race condition, after all it's not a
specific problem to kvm dirty ring but to both of the methods. I'll continue
with dirty ring for now, then we fix the race altogether with dirty log when we
find some better solution.
I'll soon post a new QEMU version, keeping the removing memslot sync operation,
but just like dirty log it'll be a best effort sync (e.g. PML ignored).
However I'll comment to at least mention the issues we've found so we can get
to it later again.
Thanks,
--
Peter Xu
prev parent reply other threads:[~2020-05-23 22:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-28 19:42 [PATCH RFC 0/4] vl: Sync dirty bitmap when system resets Peter Xu
2020-04-28 19:42 ` [PATCH RFC 1/4] migration: Export migration_bitmap_sync_precopy() Peter Xu
2020-05-06 9:58 ` Dr. David Alan Gilbert
2020-04-28 19:42 ` [PATCH RFC 2/4] migration: Introduce migrate_is_precopy() Peter Xu
2020-05-06 10:05 ` Dr. David Alan Gilbert
2020-05-06 14:52 ` Peter Xu
2020-04-28 19:42 ` [PATCH RFC 3/4] vl: Sync dirty bits for system resets during precopy Peter Xu
2020-05-06 10:53 ` Dr. David Alan Gilbert
2020-05-06 15:38 ` Peter Xu
2020-04-28 19:42 ` [PATCH RFC 4/4] kvm: No need to sync dirty bitmap before memslot removal any more Peter Xu
2020-04-29 13:26 ` [PATCH RFC 0/4] vl: Sync dirty bitmap when system resets Dr. David Alan Gilbert
2020-04-29 14:32 ` Peter Xu
2020-05-02 21:04 ` Peter Xu
2020-05-23 22:49 ` 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=20200523224932.GA939059@xz-x1 \
--to=peterx@redhat.com \
--cc=dgilbert@redhat.com \
--cc=kevin.tian@intel.com \
--cc=pbonzini@redhat.com \
--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 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).