>> That should work as expected. Resizing *while* kvm is running is tricky, but >> that‘s not part of this series and a different story :) right now, resizing >> is only valid on reboot/incoming migration. > > Hmm 'when' during an incoming migration; I ask because of userfaultfd > setup for postcopy. Also note those things can combine - i.e. a reboot > that happens during a migration (we've already got a pile of related > bugs).
Yes, resizing while migration is in progress (source already sent the rem block sizes, receiving side in postcopy), or when dumping is active is bad. In general, resizing while *somebody* thinks the used_length of a ram block won't change is bad. Incoming migration: migration/ram.c: ram_load_precopy(): RAM_SAVE_FLAG_MEM_SIZE So in preload, before the guest is running and before postcopy has started. At that point, performing the resize is fine. > >>> >>> c) It's interesting this is keyed off the RAMBlock notifiers - do >>> memory_listener's on the address space the block is mapped into get >>> triggered? I'm wondering how vhost (and vhost-user) in particular >>> see this. >> >> Yes, memory listeners get triggered. Old region is removed, new one is >> added. Nothing changed on that front. >> >> The issue with ram block notifiers is that they did not do a „remove old, >> add new“ on resizes. They only added the full ram block. Bad. E.g., vfio >> wants to pin all memory - which would fail on PROT_NONE. >> >> E.g., for HAX, there is no kernel ioctl to remove a ram block ... for SEV >> there is, but I am not sure about the implications when converting back and >> forth between encrypted/unencrypted. So SEV and HAX require legacy handling. > > I guess for a memory listener it just sees a new layout after the commit > and then can figure out what changed. Exactly. -- Thanks, David / dhildenb
