From: Bharata B Rao <bharata@linux.ibm.com>
To: Paul Mackerras <paulus@ozlabs.org>
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,
hch@lst.de
Subject: Re: [PATCH v10 3/8] KVM: PPC: Shared pages support for secure guests
Date: Wed, 6 Nov 2019 13:52:35 +0530 [thread overview]
Message-ID: <20191106082235.GC21634@in.ibm.com> (raw)
In-Reply-To: <20191106045238.GD12069@oak.ozlabs.ibm.com>
On Wed, Nov 06, 2019 at 03:52:38PM +1100, Paul Mackerras wrote:
> On Mon, Nov 04, 2019 at 09:47:55AM +0530, Bharata B Rao wrote:
> > A secure guest will share some of its pages with hypervisor (Eg. virtio
> > bounce buffers etc). Support sharing of pages between hypervisor and
> > ultravisor.
> >
> > Shared page is reachable via both HV and UV side page tables. Once a
> > secure page is converted to shared page, the device page that represents
> > the secure page is unmapped from the HV side page tables.
>
> I'd like to understand a little better what's going on - see below...
>
> > +/*
> > + * Shares the page with HV, thus making it a normal page.
> > + *
> > + * - If the page is already secure, then provision a new page and share
> > + * - If the page is a normal page, share the existing page
> > + *
> > + * In the former case, uses dev_pagemap_ops.migrate_to_ram handler
> > + * to unmap the device page from QEMU's page tables.
> > + */
> > +static unsigned long
> > +kvmppc_share_page(struct kvm *kvm, unsigned long gpa, unsigned long page_shift)
> > +{
> > +
> > + int ret = H_PARAMETER;
> > + struct page *uvmem_page;
> > + struct kvmppc_uvmem_page_pvt *pvt;
> > + unsigned long pfn;
> > + unsigned long gfn = gpa >> page_shift;
> > + int srcu_idx;
> > + unsigned long uvmem_pfn;
> > +
> > + srcu_idx = srcu_read_lock(&kvm->srcu);
> > + mutex_lock(&kvm->arch.uvmem_lock);
> > + if (kvmppc_gfn_is_uvmem_pfn(gfn, kvm, &uvmem_pfn)) {
> > + uvmem_page = pfn_to_page(uvmem_pfn);
> > + pvt = uvmem_page->zone_device_data;
> > + pvt->skip_page_out = true;
> > + }
> > +
> > +retry:
> > + mutex_unlock(&kvm->arch.uvmem_lock);
> > + pfn = gfn_to_pfn(kvm, gfn);
>
> At this point, pfn is the value obtained from the page table for
> userspace (e.g. QEMU), right?
Yes.
> I would think it should be equal to
> uvmem_pfn in most cases, shouldn't it?
Yes, in most cases (Common case is to share a page that is already secure)
> If not, what is it going to
> be?
It can be a regular pfn if non-secure page is being shared again.
>
> > + if (is_error_noslot_pfn(pfn))
> > + goto out;
> > +
> > + mutex_lock(&kvm->arch.uvmem_lock);
> > + if (kvmppc_gfn_is_uvmem_pfn(gfn, kvm, &uvmem_pfn)) {
> > + uvmem_page = pfn_to_page(uvmem_pfn);
> > + pvt = uvmem_page->zone_device_data;
> > + pvt->skip_page_out = true;
> > + kvm_release_pfn_clean(pfn);
>
> This is going to do a put_page(), unless pfn is a reserved pfn. If it
> does a put_page(), where did we do the corresponding get_page()?
gfn_to_pfn() will come with a reference held.
> However, since kvmppc_gfn_is_uvmem_pfn() returned true, doesn't that
> mean that pfn here should be a device pfn, and in fact should be the
> same as uvmem_pfn (possibly with some extra bit(s) set)?
If secure page is being converted to share, pfn will be uvmem_pfn (device pfn).
If not, it will be regular pfn.
> What does
> kvm_is_reserved_pfn() return for a device pfn?
From this code patch, we will never call kvm_release_pfn_clean() on a device
pfn. The prior call to gfn_to_pfn() would fault, result in page-out thus
converting the device pfn to regular pfn (page share request for secure page
case).
Regards,
Bharata.
next prev parent reply other threads:[~2019-11-06 8:24 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-04 4:17 [PATCH v10 0/8] KVM: PPC: Driver to manage pages of secure guest Bharata B Rao
2019-11-04 4:17 ` [PATCH v10 1/8] mm: ksm: Export ksm_madvise() Bharata B Rao
2019-11-06 4:33 ` Paul Mackerras
2019-11-06 6:45 ` Bharata B Rao
2019-11-07 5:45 ` Paul Mackerras
2019-11-15 14:10 ` Bharata B Rao
2019-11-04 4:17 ` [PATCH v10 2/8] KVM: PPC: Support for running secure guests Bharata B Rao
2019-11-06 4:34 ` Paul Mackerras
2019-11-04 4:17 ` [PATCH v10 3/8] KVM: PPC: Shared pages support for " Bharata B Rao
2019-11-06 4:52 ` Paul Mackerras
2019-11-06 8:22 ` Bharata B Rao [this message]
2019-11-06 8:29 ` Bharata B Rao
2019-11-04 4:17 ` [PATCH v10 4/8] KVM: PPC: Radix changes for secure guest Bharata B Rao
2019-11-06 5:58 ` Paul Mackerras
2019-11-06 8:36 ` Bharata B Rao
2019-11-04 4:17 ` [PATCH v10 5/8] KVM: PPC: Handle memory plug/unplug to secure VM Bharata B Rao
2019-11-11 4:25 ` Paul Mackerras
2019-11-04 4:17 ` [PATCH v10 6/8] KVM: PPC: Support reset of secure guest Bharata B Rao
2019-11-11 5:28 ` Paul Mackerras
2019-11-11 6:55 ` Bharata B Rao
2019-11-12 5:34 ` Paul Mackerras
2019-11-13 15:29 ` Bharata B Rao
2019-11-14 5:07 ` Paul Mackerras
2019-11-04 4:17 ` [PATCH v10 7/8] KVM: PPC: Implement H_SVM_INIT_ABORT hcall Bharata B Rao
2019-11-11 4:19 ` Paul Mackerras
2019-11-12 1:01 ` Ram Pai
2019-11-12 5:38 ` Paul Mackerras
2019-11-12 7:52 ` Ram Pai
2019-11-12 11:32 ` Paul Mackerras
2019-11-12 14:45 ` Ram Pai
2019-11-13 0:14 ` Paul Mackerras
2019-11-13 6:32 ` Ram Pai
2019-11-13 21:18 ` Paul Mackerras
2019-11-13 21:50 ` Ram Pai
2019-11-14 5:08 ` Paul Mackerras
2019-11-14 7:02 ` Ram Pai
2019-11-04 4:18 ` [PATCH v10 8/8] KVM: PPC: Ultravisor: Add PPC_UV config option Bharata B Rao
2019-11-06 4:30 ` [PATCH v10 0/8] KVM: PPC: Driver to manage pages of secure guest Paul Mackerras
2019-11-06 6:20 ` Bharata B Rao
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=20191106082235.GC21634@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=paulus@ozlabs.org \
--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).