[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH RFC 0/4] vl: Sync dirty bitmap when system resets
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [PATCH RFC 0/4] vl: Sync dirty bitmap when system resets |
Date: |
Wed, 29 Apr 2020 14:26:07 +0100 |
User-agent: |
Mutt/1.13.4 (2020-02-15) |
* Peter Xu (address@hidden) 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 / address@hidden / Manchester, UK