On Wed, 5 Jul 2023 14:08:27 +0100 Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > On Wed, Jul 05, 2023 at 02:46:03PM +0200, Claudio Imbrenda wrote: > > On Wed, 5 Jul 2023 13:26:32 +0100 > > Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > > > [...] > > > > > > > I rather think mgmt apps need to explicitly opt-in to async teardown, > > > > > so they're aware that they need to take account of delayed RAM > > > > > availablity in their accounting / guest placement logic. > > > > > > > > what would you think about enabling it by default only for guests that > > > > are capable to run in Secure Execution mode? > > > > > > IIUC, that's basically /all/ guests if running on new enough hardware > > > with prot_virt=1 enabled on the host OS, so will still present challenges > > > to mgmt apps needing to be aware of this behaviour AFAICS. > > > > I think there is some fencing still? I don't think it's automatic > > IIUC, the following sequence is possible > > 1. Start QEMU with -m 500G > -> QEMU spawns async teardown helper process > 2. Stop QEMU > -> Async teardown helper process remains running while not running, the process terminates immediately as soon as QEMU terminates. the termination takes some time, because of the memory cleanup. > kernel releases RAM > 3. Start QEMU with -m 500G > -> Fails with ENOMEM why though? the new VM will not manage to instantly use all of the memory > ...time passes... > 4. Async teardown helper finally terminates > -> The full original 500G is only now released for use memory starts to get freed as soon as the helper process terminates (which is as immediately as possible after QEMU terminates so unless you have a guest that will allocate and use all of its memory immediately as fast as possible at boot, this won't be a concern. > > Basically if you can't do > > while true > do > virsh start $guest > virsh stop $guest > done > > then it is a change in libvirt API semantics, as so will require > explicit opt-in from the mgmt app to use this feature. this is still true, though, because you __could__ have a guest that zeroes out (or otherwise touches) all memory immediately when booting, I guess? see Thomas' comment, though > > With regards, > Daniel
