From: Bharata B Rao <bharata@linux.ibm.com>
To: Christoph Hellwig <hch@lst.de>
Cc: linuxram@us.ibm.com, cclaudio@linux.ibm.com,
kvm-ppc@vger.kernel.org, linux-mm@kvack.org, jglisse@redhat.com,
aneesh.kumar@linux.vnet.ibm.com, paulus@au1.ibm.com,
sukadev@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v7 1/7] kvmppc: Driver to manage pages of secure guest
Date: Fri, 30 Aug 2019 09:12:59 +0530 [thread overview]
Message-ID: <20190830034259.GD31913@in.ibm.com> (raw)
In-Reply-To: <20190829083810.GA13039@lst.de>
On Thu, Aug 29, 2019 at 10:38:10AM +0200, Christoph Hellwig wrote:
> On Thu, Aug 22, 2019 at 03:56:14PM +0530, Bharata B Rao wrote:
> > +/*
> > + * Bits 60:56 in the rmap entry will be used to identify the
> > + * different uses/functions of rmap.
> > + */
> > +#define KVMPPC_RMAP_DEVM_PFN (0x2ULL << 56)
>
> How did you come up with this specific value?
Different usage types of RMAP array are being defined.
https://patchwork.ozlabs.org/patch/1149791/
The above value is reserved for device pfn usage.
>
> > +
> > +static inline bool kvmppc_rmap_is_devm_pfn(unsigned long pfn)
> > +{
> > + return !!(pfn & KVMPPC_RMAP_DEVM_PFN);
> > +}
>
> No need for !! when returning a bool. Also the helper seems a little
> pointless, just opencoding it would make the code more readable in my
> opinion.
I expect similar routines for other usages of RMAP to come up.
>
> > +#ifdef CONFIG_PPC_UV
> > +extern int kvmppc_devm_init(void);
> > +extern void kvmppc_devm_free(void);
>
> There is no need for extern in a function declaration.
>
> > +static int
> > +kvmppc_devm_migrate_alloc_and_copy(struct migrate_vma *mig,
> > + unsigned long *rmap, unsigned long gpa,
> > + unsigned int lpid, unsigned long page_shift)
> > +{
> > + struct page *spage = migrate_pfn_to_page(*mig->src);
> > + unsigned long pfn = *mig->src >> MIGRATE_PFN_SHIFT;
> > + struct page *dpage;
> > +
> > + *mig->dst = 0;
> > + if (!spage || !(*mig->src & MIGRATE_PFN_MIGRATE))
> > + return 0;
> > +
> > + dpage = kvmppc_devm_get_page(rmap, gpa, lpid);
> > + if (!dpage)
> > + return -EINVAL;
> > +
> > + if (spage)
> > + uv_page_in(lpid, pfn << page_shift, gpa, 0, page_shift);
> > +
> > + *mig->dst = migrate_pfn(page_to_pfn(dpage)) | MIGRATE_PFN_LOCKED;
> > + return 0;
> > +}
>
> I think you can just merge this trivial helper into the only caller.
Yes I can, but felt it is nicely abstracted out to a function right now.
>
> > +static int
> > +kvmppc_devm_fault_migrate_alloc_and_copy(struct migrate_vma *mig,
> > + unsigned long page_shift)
> > +{
> > + struct page *dpage, *spage;
> > + struct kvmppc_devm_page_pvt *pvt;
> > + unsigned long pfn;
> > + int ret;
> > +
> > + spage = migrate_pfn_to_page(*mig->src);
> > + if (!spage || !(*mig->src & MIGRATE_PFN_MIGRATE))
> > + return 0;
> > + if (!is_zone_device_page(spage))
> > + return 0;
> > +
> > + dpage = alloc_page_vma(GFP_HIGHUSER, mig->vma, mig->start);
> > + if (!dpage)
> > + return -EINVAL;
> > + lock_page(dpage);
> > + pvt = spage->zone_device_data;
> > +
> > + pfn = page_to_pfn(dpage);
> > + ret = uv_page_out(pvt->lpid, pfn << page_shift, pvt->gpa, 0,
> > + page_shift);
> > + if (ret == U_SUCCESS)
> > + *mig->dst = migrate_pfn(pfn) | MIGRATE_PFN_LOCKED;
> > + else {
> > + unlock_page(dpage);
> > + __free_page(dpage);
> > + }
> > + return ret;
> > +}
>
> Here we actually have two callers, but they have a fair amount of
> duplicate code in them. I think you want to move that common
> code (including setting up the migrate_vma structure) into this
> function and maybe also give it a more descriptive name.
Sure, I will give this a try. The name is already very descriptive, will
come up with an appropriate name.
BTW this file and the fuction prefixes in this file started out with
kvmppc_hmm, switched to kvmppc_devm when HMM routines weren't used anymore.
Now with the use of only non-dev versions, planning to swtich to
kvmppc_uvmem_
>
> > +static void kvmppc_devm_page_free(struct page *page)
> > +{
> > + unsigned long pfn = page_to_pfn(page);
> > + unsigned long flags;
> > + struct kvmppc_devm_page_pvt *pvt;
> > +
> > + spin_lock_irqsave(&kvmppc_devm_pfn_lock, flags);
> > + pvt = page->zone_device_data;
> > + page->zone_device_data = NULL;
> > +
> > + bitmap_clear(kvmppc_devm_pfn_bitmap,
> > + pfn - (kvmppc_devm_pgmap.res.start >> PAGE_SHIFT), 1);
>
> Nit: I'd just initialize pfn to the value you want from the start.
> That makes the code a little easier to read, and keeps a tiny bit more
> code outside the spinlock.
>
> unsigned long pfn = page_to_pfn(page) -
> (kvmppc_devm_pgmap.res.start >> PAGE_SHIFT);
>
> ..
>
> bitmap_clear(kvmppc_devm_pfn_bitmap, pfn, 1);
Sure.
>
>
> > + kvmppc_devm_pgmap.type = MEMORY_DEVICE_PRIVATE;
> > + kvmppc_devm_pgmap.res = *res;
> > + kvmppc_devm_pgmap.ops = &kvmppc_devm_ops;
> > + addr = memremap_pages(&kvmppc_devm_pgmap, -1);
>
> This -1 should be NUMA_NO_NODE for clarity.
Right.
Regards,
Bharata.
next prev parent reply other threads:[~2019-08-30 3:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-22 10:26 [PATCH v7 0/7] KVMPPC driver to manage secure guest pages Bharata B Rao
2019-08-22 10:26 ` [PATCH v7 1/7] kvmppc: Driver to manage pages of secure guest Bharata B Rao
2019-08-29 3:02 ` Sukadev Bhattiprolu
2019-08-29 6:56 ` Bharata B Rao
2019-08-29 19:39 ` Sukadev Bhattiprolu
2019-08-30 11:13 ` Bharata B Rao
2019-08-29 8:38 ` Christoph Hellwig
2019-08-30 3:42 ` Bharata B Rao [this message]
2019-09-02 7:53 ` Christoph Hellwig
2019-09-06 11:36 ` Bharata B Rao
2019-09-06 16:32 ` Christoph Hellwig
2019-08-22 10:26 ` [PATCH v7 2/7] kvmppc: Shared pages support for secure guests Bharata B Rao
2019-08-29 3:04 ` Sukadev Bhattiprolu
2019-08-29 6:58 ` Bharata B Rao
2019-08-22 10:26 ` [PATCH v7 3/7] kvmppc: H_SVM_INIT_START and H_SVM_INIT_DONE hcalls Bharata B Rao
2019-08-22 10:26 ` [PATCH v7 4/7] kvmppc: Handle memory plug/unplug to secure VM Bharata B Rao
2019-08-29 8:39 ` Christoph Hellwig
2019-08-22 10:26 ` [PATCH v7 5/7] kvmppc: Radix changes for secure guest Bharata B Rao
2019-08-29 3:05 ` Sukadev Bhattiprolu
2019-08-29 7:57 ` Bharata B Rao
2019-08-22 10:26 ` [PATCH v7 6/7] kvmppc: Support reset of " Bharata B Rao
2019-08-22 10:26 ` [PATCH v7 7/7] KVM: PPC: Ultravisor: Add PPC_UV config option Bharata B Rao
2019-08-23 4:17 ` [PATCH v7 0/7] KVMPPC driver to manage secure guest pages Paul Mackerras
2019-08-23 6:57 ` Bharata B Rao
2019-08-23 11:57 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190830034259.GD31913@in.ibm.com \
--to=bharata@linux.ibm.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=cclaudio@linux.ibm.com \
--cc=hch@lst.de \
--cc=jglisse@redhat.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=linuxram@us.ibm.com \
--cc=paulus@au1.ibm.com \
--cc=sukadev@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).