Re: [PATCH v1 00/13] Ram blocks with resizable anonymous allocations under POSIX

[David Hildenbrand]

>> 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