On Tue, Jul 27, 2021 at 11:25:09AM +0200, David Hildenbrand wrote:
For 2) I see 3 options:
a) Sync everything, fixup the dirty bitmap, never clear the dirty log of
discarded parts. It's fairly simple and straight forward, as I can simply
reuse the existing helper. Something that's discarded will never be dirty,
not even if a misbehaving guest touches memory it shouldn't. [this patch]
b) Sync only populated parts, no need to fixup the dirty bitmap, never clear
the dirty log of discarded parts. It's a bit more complicated but achieves
the same goal as a). [optimization I propose for the future]
c) Sync everything, don't fixup the dirty bitmap, clear the dirty log of
discarded parts initially. There are ways we still might migrate discarded
ranges, for example, if a misbehaving guest touches memory it shouldn't.
[what you propose]
Is my understanding correct? Any reasons why we should chose c) over b) long
term or c) over a) short term?
My major concern is we could do something during sync() for not a very good
reason by looping over virtio-mem bitmap for disgarded ranges - IIUC it should
be destined to be merely no-op if the guest is well-behaved, am I right?
Clear dirty bitmap is as simple as "reprotect the pages" functional-wise - if
they are unplugged memory ranges, and they shouldn't be written by the guest
(we still allow reads even for virtio-mem compatibility), then I don't see it
an issue to wr-protect it using clear dirty log when bitmap init.
It still makes sense to me to keep the dirty/clear bitmap in-sync, at least
before your plan b proposal; leaving the dirty bits set forever on unplugged
memory is okay but just sounds a bit weird.
Though my concern is only valid when virtio-mem is used, so I don't have a
strong opinion on it as you maintains virtio-mem. I believe you will always
have a better judgement than me on that. Especially, when/if Dave & Juan have
no problem on that. :)