From: Bharata B Rao <bharata@linux.ibm.com>
To: Paul Mackerras <paulus@ozlabs.org>
Cc: linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
linux-mm@kvack.org, paulus@au1.ibm.com, benh@linux.ibm.com,
aneesh.kumar@linux.vnet.ibm.com, jglisse@redhat.com,
linuxram@us.ibm.com
Subject: Re: [RFC PATCH v1 2/4] kvmppc: Add support for shared pages in HMM driver
Date: Mon, 12 Nov 2018 09:50:55 +0000 [thread overview]
Message-ID: <20181112093855.GC17399@in.ibm.com> (raw)
In-Reply-To: <20181030052646.GB11072@blackberry>
On Tue, Oct 30, 2018 at 04:26:46PM +1100, Paul Mackerras wrote:
> On Mon, Oct 22, 2018 at 10:48:35AM +0530, Bharata B Rao wrote:
> > A secure guest will share some of its pages with hypervisor (Eg. virtio
> > bounce buffers etc). Support shared pages in HMM driver.
> >
> > Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
>
> Comments below...
>
> > ---
> > arch/powerpc/kvm/book3s_hv_hmm.c | 69 ++++++++++++++++++++++++++++++--
> > 1 file changed, 65 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/powerpc/kvm/book3s_hv_hmm.c b/arch/powerpc/kvm/book3s_hv_hmm.c
> > index a2ee3163a312..09b8e19b7605 100644
> > --- a/arch/powerpc/kvm/book3s_hv_hmm.c
> > +++ b/arch/powerpc/kvm/book3s_hv_hmm.c
> > @@ -50,6 +50,7 @@ struct kvmppc_hmm_page_pvt {
> > struct hlist_head *hmm_hash;
> > unsigned int lpid;
> > unsigned long gpa;
> > + bool skip_page_out;
> > };
> >
> > struct kvmppc_hmm_migrate_args {
> > @@ -278,6 +279,65 @@ static unsigned long kvmppc_gpa_to_hva(struct kvm *kvm, unsigned long gpa,
> > return hva;
> > }
> >
> > +/*
> > + * 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 the HMM fault handler to release the HMM page.
> > + */
> > +static unsigned long
> > +kvmppc_share_page(struct kvm *kvm, unsigned long gpa,
> > + unsigned long addr, unsigned long page_shift)
> > +{
> > +
> > + int ret;
> > + struct hlist_head *list, *hmm_hash;
> > + unsigned int lpid = kvm->arch.lpid;
> > + unsigned long flags;
> > + struct kvmppc_hmm_pfn_entry *p;
> > + struct page *hmm_page, *page;
> > + struct kvmppc_hmm_page_pvt *pvt;
> > + unsigned long pfn;
> > +
> > + /*
> > + * First check if the requested page has already been given to
> > + * UV as a secure page. If so, ensure that we don't issue a
> > + * UV_PAGE_OUT but instead directly send the page
> > + */
> > + spin_lock_irqsave(&kvmppc_hmm_lock, flags);
> > + hmm_hash = kvm->arch.hmm_hash;
> > + list = &hmm_hash[kvmppc_hmm_pfn_hash_fn(gpa)];
> > + hlist_for_each_entry(p, list, hlist) {
> > + if (p->addr = gpa) {
> > + hmm_page = pfn_to_page(p->hmm_pfn);
> > + get_page(hmm_page); /* TODO: Necessary ? */
> > + pvt = (struct kvmppc_hmm_page_pvt *)
> > + hmm_devmem_page_get_drvdata(hmm_page);
> > + pvt->skip_page_out = true;
> > + put_page(hmm_page);
> > + break;
> > + }
> > + }
> > + spin_unlock_irqrestore(&kvmppc_hmm_lock, flags);
> > +
> > + ret = get_user_pages_fast(addr, 1, 0, &page);
>
> Why are we calling this with write=0? Surely in general the secure
> guest will expect to be able to write to the shared page?
>
> Also, in general get_user_pages_fast isn't sufficient to translate a
> host virtual address (derived from a guest real address) into a pfn.
> See for example hva_to_pfn() in virt/kvm/kvm_main.c and the things it
> does to cope with the various cases that one can hit. I can imagine
> in future that the secure guest might want to establish a shared
> mapping to a PCI device, for instance.
I switched to using gfn_to_pfn() which should cover all the cases.
>
> > + if (ret != 1)
> > + return H_PARAMETER;
> > +
> > + pfn = page_to_pfn(page);
> > + if (is_zero_pfn(pfn)) {
> > + put_page(page);
> > + return H_SUCCESS;
> > + }
>
> The ultravisor still needs a page to map into the guest in this case,
> doesn't it? What's the point of returning without giving the
> ultravisor a page to use?
Yes, missed it.
Regards,
Bharata.
WARNING: multiple messages have this Message-ID (diff)
From: Bharata B Rao <bharata@linux.ibm.com>
To: Paul Mackerras <paulus@ozlabs.org>
Cc: linuxram@us.ibm.com, kvm-ppc@vger.kernel.org, benh@linux.ibm.com,
linux-mm@kvack.org, jglisse@redhat.com,
aneesh.kumar@linux.vnet.ibm.com, paulus@au1.ibm.com,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC PATCH v1 2/4] kvmppc: Add support for shared pages in HMM driver
Date: Mon, 12 Nov 2018 15:08:55 +0530 [thread overview]
Message-ID: <20181112093855.GC17399@in.ibm.com> (raw)
In-Reply-To: <20181030052646.GB11072@blackberry>
On Tue, Oct 30, 2018 at 04:26:46PM +1100, Paul Mackerras wrote:
> On Mon, Oct 22, 2018 at 10:48:35AM +0530, Bharata B Rao wrote:
> > A secure guest will share some of its pages with hypervisor (Eg. virtio
> > bounce buffers etc). Support shared pages in HMM driver.
> >
> > Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
>
> Comments below...
>
> > ---
> > arch/powerpc/kvm/book3s_hv_hmm.c | 69 ++++++++++++++++++++++++++++++--
> > 1 file changed, 65 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/powerpc/kvm/book3s_hv_hmm.c b/arch/powerpc/kvm/book3s_hv_hmm.c
> > index a2ee3163a312..09b8e19b7605 100644
> > --- a/arch/powerpc/kvm/book3s_hv_hmm.c
> > +++ b/arch/powerpc/kvm/book3s_hv_hmm.c
> > @@ -50,6 +50,7 @@ struct kvmppc_hmm_page_pvt {
> > struct hlist_head *hmm_hash;
> > unsigned int lpid;
> > unsigned long gpa;
> > + bool skip_page_out;
> > };
> >
> > struct kvmppc_hmm_migrate_args {
> > @@ -278,6 +279,65 @@ static unsigned long kvmppc_gpa_to_hva(struct kvm *kvm, unsigned long gpa,
> > return hva;
> > }
> >
> > +/*
> > + * 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 the HMM fault handler to release the HMM page.
> > + */
> > +static unsigned long
> > +kvmppc_share_page(struct kvm *kvm, unsigned long gpa,
> > + unsigned long addr, unsigned long page_shift)
> > +{
> > +
> > + int ret;
> > + struct hlist_head *list, *hmm_hash;
> > + unsigned int lpid = kvm->arch.lpid;
> > + unsigned long flags;
> > + struct kvmppc_hmm_pfn_entry *p;
> > + struct page *hmm_page, *page;
> > + struct kvmppc_hmm_page_pvt *pvt;
> > + unsigned long pfn;
> > +
> > + /*
> > + * First check if the requested page has already been given to
> > + * UV as a secure page. If so, ensure that we don't issue a
> > + * UV_PAGE_OUT but instead directly send the page
> > + */
> > + spin_lock_irqsave(&kvmppc_hmm_lock, flags);
> > + hmm_hash = kvm->arch.hmm_hash;
> > + list = &hmm_hash[kvmppc_hmm_pfn_hash_fn(gpa)];
> > + hlist_for_each_entry(p, list, hlist) {
> > + if (p->addr == gpa) {
> > + hmm_page = pfn_to_page(p->hmm_pfn);
> > + get_page(hmm_page); /* TODO: Necessary ? */
> > + pvt = (struct kvmppc_hmm_page_pvt *)
> > + hmm_devmem_page_get_drvdata(hmm_page);
> > + pvt->skip_page_out = true;
> > + put_page(hmm_page);
> > + break;
> > + }
> > + }
> > + spin_unlock_irqrestore(&kvmppc_hmm_lock, flags);
> > +
> > + ret = get_user_pages_fast(addr, 1, 0, &page);
>
> Why are we calling this with write==0? Surely in general the secure
> guest will expect to be able to write to the shared page?
>
> Also, in general get_user_pages_fast isn't sufficient to translate a
> host virtual address (derived from a guest real address) into a pfn.
> See for example hva_to_pfn() in virt/kvm/kvm_main.c and the things it
> does to cope with the various cases that one can hit. I can imagine
> in future that the secure guest might want to establish a shared
> mapping to a PCI device, for instance.
I switched to using gfn_to_pfn() which should cover all the cases.
>
> > + if (ret != 1)
> > + return H_PARAMETER;
> > +
> > + pfn = page_to_pfn(page);
> > + if (is_zero_pfn(pfn)) {
> > + put_page(page);
> > + return H_SUCCESS;
> > + }
>
> The ultravisor still needs a page to map into the guest in this case,
> doesn't it? What's the point of returning without giving the
> ultravisor a page to use?
Yes, missed it.
Regards,
Bharata.
WARNING: multiple messages have this Message-ID (diff)
From: Bharata B Rao <bharata@linux.ibm.com>
To: Paul Mackerras <paulus@ozlabs.org>
Cc: linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
linux-mm@kvack.org, paulus@au1.ibm.com, benh@linux.ibm.com,
aneesh.kumar@linux.vnet.ibm.com, jglisse@redhat.com,
linuxram@us.ibm.com
Subject: Re: [RFC PATCH v1 2/4] kvmppc: Add support for shared pages in HMM driver
Date: Mon, 12 Nov 2018 15:08:55 +0530 [thread overview]
Message-ID: <20181112093855.GC17399@in.ibm.com> (raw)
In-Reply-To: <20181030052646.GB11072@blackberry>
On Tue, Oct 30, 2018 at 04:26:46PM +1100, Paul Mackerras wrote:
> On Mon, Oct 22, 2018 at 10:48:35AM +0530, Bharata B Rao wrote:
> > A secure guest will share some of its pages with hypervisor (Eg. virtio
> > bounce buffers etc). Support shared pages in HMM driver.
> >
> > Signed-off-by: Bharata B Rao <bharata@linux.ibm.com>
>
> Comments below...
>
> > ---
> > arch/powerpc/kvm/book3s_hv_hmm.c | 69 ++++++++++++++++++++++++++++++--
> > 1 file changed, 65 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/powerpc/kvm/book3s_hv_hmm.c b/arch/powerpc/kvm/book3s_hv_hmm.c
> > index a2ee3163a312..09b8e19b7605 100644
> > --- a/arch/powerpc/kvm/book3s_hv_hmm.c
> > +++ b/arch/powerpc/kvm/book3s_hv_hmm.c
> > @@ -50,6 +50,7 @@ struct kvmppc_hmm_page_pvt {
> > struct hlist_head *hmm_hash;
> > unsigned int lpid;
> > unsigned long gpa;
> > + bool skip_page_out;
> > };
> >
> > struct kvmppc_hmm_migrate_args {
> > @@ -278,6 +279,65 @@ static unsigned long kvmppc_gpa_to_hva(struct kvm *kvm, unsigned long gpa,
> > return hva;
> > }
> >
> > +/*
> > + * 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 the HMM fault handler to release the HMM page.
> > + */
> > +static unsigned long
> > +kvmppc_share_page(struct kvm *kvm, unsigned long gpa,
> > + unsigned long addr, unsigned long page_shift)
> > +{
> > +
> > + int ret;
> > + struct hlist_head *list, *hmm_hash;
> > + unsigned int lpid = kvm->arch.lpid;
> > + unsigned long flags;
> > + struct kvmppc_hmm_pfn_entry *p;
> > + struct page *hmm_page, *page;
> > + struct kvmppc_hmm_page_pvt *pvt;
> > + unsigned long pfn;
> > +
> > + /*
> > + * First check if the requested page has already been given to
> > + * UV as a secure page. If so, ensure that we don't issue a
> > + * UV_PAGE_OUT but instead directly send the page
> > + */
> > + spin_lock_irqsave(&kvmppc_hmm_lock, flags);
> > + hmm_hash = kvm->arch.hmm_hash;
> > + list = &hmm_hash[kvmppc_hmm_pfn_hash_fn(gpa)];
> > + hlist_for_each_entry(p, list, hlist) {
> > + if (p->addr == gpa) {
> > + hmm_page = pfn_to_page(p->hmm_pfn);
> > + get_page(hmm_page); /* TODO: Necessary ? */
> > + pvt = (struct kvmppc_hmm_page_pvt *)
> > + hmm_devmem_page_get_drvdata(hmm_page);
> > + pvt->skip_page_out = true;
> > + put_page(hmm_page);
> > + break;
> > + }
> > + }
> > + spin_unlock_irqrestore(&kvmppc_hmm_lock, flags);
> > +
> > + ret = get_user_pages_fast(addr, 1, 0, &page);
>
> Why are we calling this with write==0? Surely in general the secure
> guest will expect to be able to write to the shared page?
>
> Also, in general get_user_pages_fast isn't sufficient to translate a
> host virtual address (derived from a guest real address) into a pfn.
> See for example hva_to_pfn() in virt/kvm/kvm_main.c and the things it
> does to cope with the various cases that one can hit. I can imagine
> in future that the secure guest might want to establish a shared
> mapping to a PCI device, for instance.
I switched to using gfn_to_pfn() which should cover all the cases.
>
> > + if (ret != 1)
> > + return H_PARAMETER;
> > +
> > + pfn = page_to_pfn(page);
> > + if (is_zero_pfn(pfn)) {
> > + put_page(page);
> > + return H_SUCCESS;
> > + }
>
> The ultravisor still needs a page to map into the guest in this case,
> doesn't it? What's the point of returning without giving the
> ultravisor a page to use?
Yes, missed it.
Regards,
Bharata.
next prev parent reply other threads:[~2018-11-12 9:50 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-22 5:18 [RFC PATCH v1 0/4] kvmppc: HMM backend driver to manage pages of secure guest Bharata B Rao
2018-10-22 5:30 ` Bharata B Rao
2018-10-22 5:18 ` Bharata B Rao
2018-10-22 5:18 ` [RFC PATCH v1 1/4] " Bharata B Rao
2018-10-22 5:30 ` Bharata B Rao
2018-10-22 5:18 ` Bharata B Rao
2018-10-30 5:03 ` Paul Mackerras
2018-10-30 5:03 ` Paul Mackerras
2018-10-30 5:03 ` Paul Mackerras
2018-10-30 6:31 ` Ram Pai
2018-10-30 6:31 ` Ram Pai
2018-10-30 6:31 ` Ram Pai
2018-10-30 6:32 ` Paul Mackerras
2018-10-30 6:32 ` Paul Mackerras
2018-10-30 6:32 ` Paul Mackerras
2018-11-12 9:28 ` Bharata B Rao
2018-11-12 9:40 ` Bharata B Rao
2018-11-12 9:28 ` Bharata B Rao
2018-11-01 6:43 ` Balbir Singh
2018-11-01 6:43 ` Balbir Singh
2018-11-01 6:43 ` Balbir Singh
2018-11-12 9:59 ` Bharata B Rao
2018-11-12 10:11 ` Bharata B Rao
2018-11-12 9:59 ` Bharata B Rao
2018-10-22 5:18 ` [RFC PATCH v1 2/4] kvmppc: Add support for shared pages in HMM driver Bharata B Rao
2018-10-22 5:30 ` Bharata B Rao
2018-10-22 5:18 ` Bharata B Rao
2018-10-30 5:26 ` Paul Mackerras
2018-10-30 5:26 ` Paul Mackerras
2018-10-30 5:26 ` Paul Mackerras
2018-11-12 9:38 ` Bharata B Rao [this message]
2018-11-12 9:50 ` Bharata B Rao
2018-11-12 9:38 ` Bharata B Rao
2018-11-01 10:45 ` Balbir Singh
2018-11-01 10:45 ` Balbir Singh
2018-11-01 10:45 ` Balbir Singh
2018-11-12 10:07 ` Bharata B Rao
2018-11-12 10:19 ` Bharata B Rao
2018-11-12 10:07 ` Bharata B Rao
2018-10-22 5:18 ` [RFC PATCH v1 3/4] kvmppc: H_SVM_INIT_START and H_SVM_INIT_DONE hcalls Bharata B Rao
2018-10-22 5:30 ` Bharata B Rao
2018-10-22 5:18 ` Bharata B Rao
2018-10-30 5:29 ` Paul Mackerras
2018-10-30 5:29 ` Paul Mackerras
2018-10-30 5:29 ` Paul Mackerras
2018-11-12 9:39 ` Bharata B Rao
2018-11-12 9:51 ` Bharata B Rao
2018-11-12 9:39 ` Bharata B Rao
2018-11-01 10:49 ` Balbir Singh
2018-11-01 10:49 ` Balbir Singh
2018-11-01 10:49 ` Balbir Singh
2018-11-12 10:08 ` Bharata B Rao
2018-11-12 10:20 ` Bharata B Rao
2018-11-12 10:08 ` Bharata B Rao
2018-10-22 5:18 ` [RFC PATCH v1 4/4] kvmppc: Handle memory plug/unplug to secure VM Bharata B Rao
2018-10-22 5:30 ` Bharata B Rao
2018-10-22 5:18 ` 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=20181112093855.GC17399@in.ibm.com \
--to=bharata@linux.ibm.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=benh@linux.ibm.com \
--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 \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.