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

[Peter Xu]

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