On Mon, Jul 27, 2020 at 11:07:13AM -0700, Ram Pai wrote: > The time to switch a VM to Secure-VM, increases by the size of the VM. > A 100GB VM takes about 7minutes. This is unacceptable. This linear > increase is caused by a suboptimal behavior by the Ultravisor and the > Hypervisor. The Ultravisor unnecessarily migrates all the GFN of the > VM from normal-memory to secure-memory. It has to just migrate the > necessary and sufficient GFNs. > > However when the optimization is incorporated in the Ultravisor, the > Hypervisor starts misbehaving. The Hypervisor has a inbuilt assumption > that the Ultravisor will explicitly request to migrate, each and every > GFN of the VM. If only necessary and sufficient GFNs are requested for > migration, the Hypervisor continues to manage the remaining GFNs as > normal GFNs. This leads to memory corruption; manifested > consistently when the SVM reboots. > > The same is true, when a memory slot is hotplugged into a SVM. The > Hypervisor expects the ultravisor to request migration of all GFNs to > secure-GFN. But the hypervisor cannot handle any H_SVM_PAGE_IN > requests from the Ultravisor, done in the context of > UV_REGISTER_MEM_SLOT ucall. This problem manifests as random errors > in the SVM, when a memory-slot is hotplugged. > > This patch series automatically migrates the non-migrated pages of a > SVM, and thus solves the problem. > > Testing: Passed rigorous testing using various sized SVMs.
Thanks, series applied to my kvm-ppc-next branch and pull request sent. Paul.
