On Tue, 11 Jul 2023 09:17:00 +0100
Daniel P. Berrangé <berrange(a)redhat.com> 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 :)