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

Daniel P. Berrangé berrange at redhat.com
Wed Jul 5 13:08:27 UTC 2023


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
         kernel releases RAM
  3. Start QEMU with -m 500G
      -> Fails with ENOMEM
  ...time passes...
  4. Async teardown helper finally terminates
      -> The full original 500G is only now released for use

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.

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


More information about the libvir-list mailing list