On Fri, Mar 17, 2023 at 10:13:22PM -0700, Isaku Yamahata wrote: > On Mon, Feb 20, 2023 at 12:37:54PM -0600, > Michael Roth <michael.roth@xxxxxxx> wrote: > > > In some cases, like with SEV-SNP, guest memory needs to be updated in a > > platform-specific manner before it can be safely freed back to the host. > > Add hooks to wire up handling of this sort to the invalidation notifiers > > for restricted memory. > > > > Also issue invalidations of all allocated pages during notifier/memslot > > unbinding so that the pages are not left in an unusable state when > > they eventually get freed back to the host upon FD release. > > I'm just curios. Could you please elaborate? > Unbind is happen only when memory slot is delete or vm is destroyed. In the > case of memory slot deletion, the gpa region is zapped via > kvm_arch_commit_memory_region(). In the case of VM destroy, we have > kvm_flush_shadow_all() which calls > kvm_arch_flush_shadow_all() =>kvm_mmu_zap_all(). Doesn't it work? The main thing here is unbind happens right before the restrictedmem pages are released back to the host, and for SNP we need to clear the associated RMP table entries to switch them from guest-owned to hypervisor-owned. It doesn't necessarily need to be a separate callback, but I'm not sure if it makes sense to squash that down into the various MMU zapping helpers. -Mike > > Thanks, > -- > Isaku Yamahata <isaku.yamahata@xxxxxxxxx>
