On Tue, 11 Jul 2023 09:17:00 +0100 Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: [...] > > We could add additional time depending on the guest memory size BUT with > > Secure Execution the timeout would need to be increased by factors (two > > digits). Also for libvirt it is not possible to detect if the guest is in > > Secure Execution mode. > > What component is causing this 2 orders of magnitude delay in shutting Secure Execution (protected VMs) > down a guest ? If the host can't tell if Secure Execution mode is > enabled or not, why would any code path be different & slower ? The host kernel (and QEMU) know if a specific VM is running in secure mode, but there is no meaningful way for this information to be communicated outwards (e.g. to libvirt) During teardown, the host kernel will need to do some time-consuming extra cleanup for each page that belonged to a secure guest. > > > I also assume that timeouts of +1h are not acceptable. Wouldn't a long > > timeout cause other trouble like stalling "virsh list" run in parallel? > > Well a 1 hour timeout is pretty insane, even with the async teardown I think we all agree, and that's why asynchronous teardown was implemented > that's terrible as RAM is unable to be used for any new guest for > an incredibly long time. I'm not sure what you mean here. RAM is not kept aside until the teardown is complete; cleared pages are returned to the free pool immediately as they are cleared. i.e. when the cleanup is halfway through, half of the memory will have been freed. I just wanted to clear up those details; how libvirt can/should implement it is outside of my domain :)
