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

[Claudio Imbrenda]

On Wed, 5 Jul 2023 10:18:37 +0100
Daniel P. Berrangé <berrange at redhat.com> wrote:

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

depending on the size of the guest it can go from seconds for small
guests to dozens of minutes for huge guests

I don't have the numbers at hand for 500G

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

what would you think about enabling it by default only for guests that
are capable to run in Secure Execution mode?

> 
> With regards,
> Daniel