On Wed, Jul 05, 2023 at 02:22:37PM +0200, Claudio Imbrenda wrote: > On Wed, 5 Jul 2023 10:18:37 +0100 > Daniel P. Berrangé <berrange@xxxxxxxxxx> 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 Doesn't have to be for 500G - that was just a value i plucked out of the air. Just interested in any concrete example timings for a non-trivially small 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 > > 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? 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. 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 :|
