Message ID | 20220628135619.32410-1-imbrenda@linux.ibm.com (mailing list archive) |
---|---|
Headers | show |
Series | KVM: s390: pv: implement lazy destroy for reboot | expand |
On 6/28/22 15:56, Claudio Imbrenda wrote: > Previously, when a protected VM was rebooted or when it was shut down, > its memory was made unprotected, and then the protected VM itself was > destroyed. Looping over the whole address space can take some time, > considering the overhead of the various Ultravisor Calls (UVCs). This > means that a reboot or a shutdown would take a potentially long amount > of time, depending on the amount of used memory. > > This patchseries implements a deferred destroy mechanism for protected > guests. When a protected guest is destroyed, its memory can be cleared > in background, allowing the guest to restart or terminate significantly > faster than before. > Patches 1-12 have spent a considerable amount of time in the CI and I'd like to queue them to be able to focus on the rest of the series. Patch 9 will need two small fixups since there are two conflicts where a line was introduced before your addition of the include and the struct kvm_s390_pv mmu_notifier member. I.e. it's more of a patch history problem than a real conflict. I'd fix that up when queuing if you're ok with it?
On Thu, 14 Jul 2022 08:59:00 +0200 Janosch Frank <frankja@linux.ibm.com> wrote: > On 6/28/22 15:56, Claudio Imbrenda wrote: > > Previously, when a protected VM was rebooted or when it was shut down, > > its memory was made unprotected, and then the protected VM itself was > > destroyed. Looping over the whole address space can take some time, > > considering the overhead of the various Ultravisor Calls (UVCs). This > > means that a reboot or a shutdown would take a potentially long amount > > of time, depending on the amount of used memory. > > > > This patchseries implements a deferred destroy mechanism for protected > > guests. When a protected guest is destroyed, its memory can be cleared > > in background, allowing the guest to restart or terminate significantly > > faster than before. > > > > Patches 1-12 have spent a considerable amount of time in the CI and I'd > like to queue them to be able to focus on the rest of the series. > > Patch 9 will need two small fixups since there are two conflicts where a > line was introduced before your addition of the include and the struct > kvm_s390_pv mmu_notifier member. I.e. it's more of a patch history > problem than a real conflict. > > I'd fix that up when queuing if you're ok with it? ok for me