On Wed, Jul 05, 2023 at 05:21:21PM +0200, Thomas Huth wrote: > On 05/07/2023 16.35, Daniel P. Berrangé wrote: > > On Wed, Jul 05, 2023 at 03:29:39PM +0200, Claudio Imbrenda wrote: > > > 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. > > > > When using huge pages, QEMU should be fully allocating memory > > immediately, regardless of whether the guest OS touches all RAM. > > IIRC huge pages cannot be used with protected guests yet (Claudio, Janosch, > please confirm), so this should not be a problem here. Another non-HP scenario is where the <allocation mode="immediate"/> is set in the guest. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
