[libvirt PATCH v3 5/5] qemu: enable asynchronous teardown on s390x hosts by default

[Claudio Imbrenda]

On Wed, 5 Jul 2023 14:08:27 +0100
Daniel P. Berrangé <berrange at redhat.com> 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 at redhat.com> 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