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

[Daniel P. Berrangé]

On Wed, Jul 05, 2023 at 08:20:27AM +0200, Boris Fiuczynski wrote:
> Enable by default asynchronous teardown on S390 hosts and add tests for
> asynchronous teardown autogeneration support.
> On S390 hosts, Secure Execution guests can take a long time to shutdown,
> since the memory cleanup can take a long time.

Can you elaborate on this ?  What makes it slow, and what kind of
magnitude of slowness are we talking abuot. eg for a 500 GB guest,
what is the shutdown time for normal vs protected guest ?

>                                               Since there is no
> practical way to determine whether a S390 guest is running in Secure
> Execution mode, and since the asynchronous teardown does not impact
> normal (not Secure Execution) guests or guests without large memory
> configurations, we enable asynchronous teardown by default on S390.
> A user can select to override the default in the guest domain XML.

It feels pretty sketchy to me to be doing async teardown as a
guest arch specific behavioural change.

Its been a while since the orignal QEMU discussions, but IIRC,
async teardown is not transparent to mgmt apps.

Even if the guest has gone from QEMU/libvirt's POV, if the host
is still reclaiming memory, the guest RAM is still not available
for starting new guests. I fear this is liable to trip up memory
accounting logic in mgmt apps, in a hard to understand way because
it will be a designed in race condition.

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.

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