From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Peter Xu <peterx@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: Wed, 29 Apr 2020 14:26:07 +0100 [thread overview]
Message-ID: <20200429132607.GJ2834@work-vm> (raw)
In-Reply-To: <20200428194219.10963-1-peterx@redhat.com>
* Peter Xu (peterx@redhat.com) wrote:
> This RFC series starts from the fact that we will sync dirty bitmap when
> removing a memslot for KVM. IIUC that was majorly to maintain the dirty bitmap
> even across a system reboot.
>
> This series wants to move that sync from kvm memslot removal to system reset.
>
> (I still don't know why the reset system will still need to keep the RAM status
> before the reset. I thought things like kdump might use this to retrieve info
> from previous kernel panic, however IIUC that's not what kdump is doing now.
> Anyway, I'd be more than glad if anyone knows the real scenario behind
> this...)
Aren't there pages written by the BIOS that are read by the system as it
comes up through reset - so you need those pages intact?
(But I don't think that slot gets removed? Or does it - the bios has
some weird aliasing)
> The current solution (sync at kvm memslot removal) works in most cases, but:
>
> - it will be merely impossible to work for dirty ring, and,
Why doesn't that work with dirty ring?
> - it has an existing flaw on race condition. [1]
>
> So if system reset is the only thing we care here, I'm thinking whether we can
> move this sync explicitly to system reset so we do a global sync there instead
> of sync every time when memory layout changed and caused memory removals. I
> think it can be more explict to sync during system reset, and also with that
> context it will be far easier for kvm dirty ring to provide the same logic.
>
> This is totally RFC because I'm still trying to find whether there will be
> other cases besides system reset that we want to keep the dirty bits for a
> to-be-removed memslot (real memory removals like unplugging memory shouldn't
> matter, because we won't care about the dirty bits if it's never going to be
> there anymore, not to mention we won't allow such things during a migration).
> So far I don't see any.
I'm still unusure when slot removal happens for real; but if it's
happening for RAM on PCI devices, then that would make sense as
something you might want to keep.
Dave
> I've run some tests either using the old dirty log or dirty ring, with either
> some memory load or reboots on the source, and I see no issues so far.
>
> Comments greatly welcomed. Thanks.
>
> [1] https://lore.kernel.org/qemu-devel/20200327150425.GJ422390@xz-x1/
>
> Peter Xu (4):
> migration: Export migration_bitmap_sync_precopy()
> migration: Introduce migrate_is_precopy()
> vl: Sync dirty bits for system resets during precopy
> kvm: No need to sync dirty bitmap before memslot removal any more
>
> accel/kvm/kvm-all.c | 3 ---
> include/migration/misc.h | 2 ++
> migration/migration.c | 7 +++++++
> migration/ram.c | 10 +++++-----
> softmmu/vl.c | 16 ++++++++++++++++
> 5 files changed, 30 insertions(+), 8 deletions(-)
>
> --
> 2.24.1
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2020-04-29 13:27 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 ` Dr. David Alan Gilbert [this message]
2020-04-29 14:32 ` [PATCH RFC 0/4] vl: Sync dirty bitmap when system resets Peter Xu
2020-05-02 21:04 ` Peter Xu
2020-05-23 22:49 ` Peter 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=20200429132607.GJ2834@work-vm \
--to=dgilbert@redhat.com \
--cc=kevin.tian@intel.com \
--cc=pbonzini@redhat.com \
--cc=peterx@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).