* Peter Xu (pet...@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 / dgilb...@redhat.com / Manchester, UK