On Mon, Jun 17, 2019 at 03:31:06PM +1000, Paul Mackerras wrote:
> On Tue, May 28, 2019 at 12:19:28PM +0530, Bharata B Rao wrote:
> > HMM driver for KVM PPC to manage page transitions of
> > secure guest via H_SVM_PAGE_IN and H_SVM_PAGE_OUT hcalls.
> >
> > H_SVM_PAGE_IN: Move the content of a normal page to secure page
> > H_SVM_PAGE_OUT: Move the content of a secure page to normal page
>
> Comments below...
>
> > @@ -4421,6 +4435,7 @@ static void kvmppc_core_free_memslot_hv(struct kvm_memory_slot *free,
> > struct kvm_memory_slot *dont)
> > {
> > if (!dont || free->arch.rmap != dont->arch.rmap) {
> > + kvmppc_hmm_release_pfns(free);
>
> I don't think this is the right place to do this. The memslot will
> have no pages mapped by this time, because higher levels of code will
> have called kvmppc_core_flush_memslot_hv() before calling this.
> Releasing the pfns should be done in that function.
In fact I can get rid of kvmppc_hmm_release_pfns() totally as we don't
have to do free the HMM pages like this explicitly. During guest shutdown
all these pages are dropped when unmap_vmas() is called.
>
> > diff --git a/arch/powerpc/kvm/book3s_hv_hmm.c b/arch/powerpc/kvm/book3s_hv_hmm.c
> > new file mode 100644
> > index 000000000000..713806003da3
>
> ...
>
> > +#define KVMPPC_PFN_HMM (0x1ULL << 61)
> > +
> > +static inline bool kvmppc_is_hmm_pfn(unsigned long pfn)
> > +{
> > + return !!(pfn & KVMPPC_PFN_HMM);
> > +}
>
> Since you are putting in these values in the rmap entries, you need to
> be careful about overlaps between these values and the other uses of
> rmap entries. The value you have chosen would be in the middle of the
> LPID field for an rmap entry for a guest that has nested guests, and
> in fact kvmhv_remove_nest_rmap_range() effectively assumes that a
> non-zero rmap entry must be a list of L2 guest mappings. (This is for
> radix guests; HPT guests use the rmap entry differently, but I am
> assuming that we will enforce that only radix guests can be secure
> guests.)
Worked out with Suraj on sharing the rmap and got a well defined
bit slot for HMM PFNs in rmap.
>
> Maybe it is true that the rmap entry will be non-zero only for those
> guest pages which are not mapped on the host side, that is,
> kvmppc_radix_flush_memslot() will see !pte_present(*ptep) for any page
> of a secure guest where the rmap entry contains a HMM pfn. If that is
> so and is a deliberate part of the design, then I would like to see it
> written down in comments and commit messages so it's clear to others
> working on the code in future.
Yes, rmap entry will be non-zero only for those guest pages which are
not mapped on the host side. However as soon as guest becomes secure
we free the HV side partition scoped page tables and hence
kvmppc_radix_flush_memslot() and other such routines which lookup
kvm->arch.pgtable will no longer touch it.
>
> Suraj is working on support for nested HPT guests, which will involve
> changing the rmap format to indicate more explicitly what sort of
> entry each rmap entry is. Please work with him to define a format for
> your rmap entries that is clearly distinguishable from the others.
>
> I think it is reasonable to say that a secure guest can't have nested
> guests, at least for now, but then we should make sure to kill all
> nested guests when a guest goes secure.
Ok. Yet to figure this part out.
>
> ...
>
> > +/*
> > + * Move page from normal memory to secure memory.
> > + */
> > +unsigned long
> > +kvmppc_h_svm_page_in(struct kvm *kvm, unsigned long gpa,
> > + unsigned long flags, unsigned long page_shift)
> > +{
> > + unsigned long addr, end;
> > + unsigned long src_pfn, dst_pfn;
> > + struct kvmppc_hmm_migrate_args args;
> > + struct vm_area_struct *vma;
> > + int srcu_idx;
> > + unsigned long gfn = gpa >> page_shift;
> > + struct kvm_memory_slot *slot;
> > + unsigned long *rmap;
> > + int ret = H_SUCCESS;
> > +
> > + if (page_shift != PAGE_SHIFT)
> > + return H_P3;
> > +
> > + srcu_idx = srcu_read_lock(&kvm->srcu);
> > + slot = gfn_to_memslot(kvm, gfn);
> > + rmap = &slot->arch.rmap[gfn - slot->base_gfn];
> > + addr = gfn_to_hva(kvm, gpa >> page_shift);
> > + srcu_read_unlock(&kvm->srcu, srcu_idx);
>
> Shouldn't we keep the srcu read lock until we have finished working on
> the page?
I wasn't sure, so keeping it locked till the end in the next version.
>
> > + if (kvm_is_error_hva(addr))
> > + return H_PARAMETER;
> > +
> > + end = addr + (1UL << page_shift);
> > +
> > + if (flags)
> > + return H_P2;
> > +
> > + args.rmap = rmap;
> > + args.lpid = kvm->arch.lpid;
> > + args.gpa = gpa;
> > + args.page_shift = page_shift;
> > +
> > + down_read(&kvm->mm->mmap_sem);
> > + vma = find_vma_intersection(kvm->mm, addr, end);
> > + if (!vma || vma->vm_start > addr || vma->vm_end < end) {
> > + ret = H_PARAMETER;
> > + goto out;
> > + }
> > + ret = migrate_vma(&kvmppc_hmm_migrate_ops, vma, addr, end,
> > + &src_pfn, &dst_pfn, &args);
> > + if (ret < 0)
> > + ret = H_PARAMETER;
> > +out:
> > + up_read(&kvm->mm->mmap_sem);
> > + return ret;
> > +}
>
> ...
>
> > +/*
> > + * Move page from secure memory to normal memory.
> > + */
> > +unsigned long
> > +kvmppc_h_svm_page_out(struct kvm *kvm, unsigned long gpa,
> > + unsigned long flags, unsigned long page_shift)
> > +{
> > + unsigned long addr, end;
> > + struct vm_area_struct *vma;
> > + unsigned long src_pfn, dst_pfn = 0;
> > + int srcu_idx;
> > + int ret = H_SUCCESS;
> > +
> > + if (page_shift != PAGE_SHIFT)
> > + return H_P3;
> > +
> > + if (flags)
> > + return H_P2;
> > +
> > + srcu_idx = srcu_read_lock(&kvm->srcu);
> > + addr = gfn_to_hva(kvm, gpa >> page_shift);
> > + srcu_read_unlock(&kvm->srcu, srcu_idx);
>
> and likewise here, shouldn't we unlock later, after the migrate_vma()
> call perhaps?
Sure.
Regards,
Bharata.
