Re: [PATCH RFC 0/4] vl: Sync dirty bitmap when system resets

["Dr. David Alan Gilbert" <dgilbert@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