From: Bharata B Rao <hidden> Date: 2019-08-22 10:26:42
Hi,
A pseries guest can be run as a secure guest on Ultravisor-enabled
POWER platforms. On such platforms, this driver will be used to manage
the movement of guest pages between the normal memory managed by
hypervisor(HV) and secure memory managed by Ultravisor(UV).
Private ZONE_DEVICE memory equal to the amount of secure memory
available in the platform for running secure guests is created.
Whenever a page belonging to the guest becomes secure, a page from
this private device memory is used to represent and track that secure
page on the HV side. The movement of pages between normal and secure
memory is done via migrate_vma_pages(). The reverse movement is driven
via pagemap_ops.migrate_to_ram().
The page-in or page-out requests from UV will come to HV as hcalls and
HV will call back into UV via uvcalls to satisfy these page requests.
These patches are against hmm.git
(https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=hmm)
plus
Claudio Carvalho's base ultravisor enablement patchset v6
(https://lore.kernel.org/linuxppc-dev/20190822034838.27876-1-cclaudio@linux.ibm.com/T/#t)
These patches along with Claudio's above patches are required to
run a secure pseries guest on KVM. This patchset is based on hmm.git
because hmm.git has migrate_vma cleanup and not-device memremap_pages
patchsets that are required by this patchset.
Changes in v7
=============
- The major change in this version is to not create a char device but
instead use the not device versions of memremap_pages and
request_free_mem_region (Christoph Hellwig)
- Other changes
* Addressed all the changes suggested by Christoph Hellwig for v6.
* Removed MIGRATE_VMA_HELPER dependency
* Switched to using of_find_compatible_node() and not doing
find by path (Thiago Jung Bauermann)
* Moved kvmppc_rmap_is_devm_pfn to kvm_host.h
* Updated comments
* use @page_shift argument in H_SVM_PAGE_OUT instead of PAGE_SHIFT
* Proper handling of return val from kvmppc_devm_fault_migrate_alloc_and_copy
v6: https://lore.kernel.org/linuxppc-dev/20190809084108.30343-1-bharata@linux.ibm.com/T/#t
Anshuman Khandual (1):
KVM: PPC: Ultravisor: Add PPC_UV config option
Bharata B Rao (6):
kvmppc: Driver to manage pages of secure guest
kvmppc: Shared pages support for secure guests
kvmppc: H_SVM_INIT_START and H_SVM_INIT_DONE hcalls
kvmppc: Handle memory plug/unplug to secure VM
kvmppc: Radix changes for secure guest
kvmppc: Support reset of secure guest
Documentation/virtual/kvm/api.txt | 19 +
arch/powerpc/Kconfig | 17 +
arch/powerpc/include/asm/hvcall.h | 9 +
arch/powerpc/include/asm/kvm_book3s_devm.h | 47 ++
arch/powerpc/include/asm/kvm_host.h | 39 ++
arch/powerpc/include/asm/kvm_ppc.h | 2 +
arch/powerpc/include/asm/ultravisor-api.h | 6 +
arch/powerpc/include/asm/ultravisor.h | 36 ++
arch/powerpc/kvm/Makefile | 3 +
arch/powerpc/kvm/book3s_64_mmu_radix.c | 22 +
arch/powerpc/kvm/book3s_hv.c | 113 ++++
arch/powerpc/kvm/book3s_hv_devm.c | 614 +++++++++++++++++++++
arch/powerpc/kvm/powerpc.c | 12 +
include/uapi/linux/kvm.h | 1 +
14 files changed, 940 insertions(+)
create mode 100644 arch/powerpc/include/asm/kvm_book3s_devm.h
create mode 100644 arch/powerpc/kvm/book3s_hv_devm.c
--
2.21.0
From: Bharata B Rao <hidden> Date: 2019-08-22 10:26:45
KVMPPC driver 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
Private ZONE_DEVICE memory equal to the amount of secure memory
available in the platform for running secure guests is created.
Whenever a page belonging to the guest becomes secure, a page from
this private device memory is used to represent and track that secure
page on the HV side. The movement of pages between normal and secure
memory is done via migrate_vma_pages() using UV_PAGE_IN and
UV_PAGE_OUT ucalls.
Signed-off-by: Bharata B Rao <redacted>
---
arch/powerpc/include/asm/hvcall.h | 4 +
arch/powerpc/include/asm/kvm_book3s_devm.h | 29 ++
arch/powerpc/include/asm/kvm_host.h | 23 ++
arch/powerpc/include/asm/ultravisor-api.h | 2 +
arch/powerpc/include/asm/ultravisor.h | 14 +
arch/powerpc/kvm/Makefile | 3 +
arch/powerpc/kvm/book3s_hv.c | 19 +
arch/powerpc/kvm/book3s_hv_devm.c | 438 +++++++++++++++++++++
8 files changed, 532 insertions(+)
create mode 100644 arch/powerpc/include/asm/kvm_book3s_devm.h
create mode 100644 arch/powerpc/kvm/book3s_hv_devm.c
From: Bharata B Rao <hidden> Date: 2019-08-22 10:26:49
A secure guest will share some of its pages with hypervisor (Eg. virtio
bounce buffers etc). Support sharing of pages between hypervisor and
ultravisor.
Once a secure page is converted to shared page, the device page is
unmapped from the HV side page tables.
Signed-off-by: Bharata B Rao <redacted>
---
arch/powerpc/include/asm/hvcall.h | 3 ++
arch/powerpc/kvm/book3s_hv_devm.c | 70 +++++++++++++++++++++++++++++--
2 files changed, 69 insertions(+), 4 deletions(-)
From: Bharata B Rao <hidden> Date: 2019-08-22 10:26:51
H_SVM_INIT_START: Initiate securing a VM
H_SVM_INIT_DONE: Conclude securing a VM
As part of H_SVM_INIT_START, register all existing memslots with
the UV. H_SVM_INIT_DONE call by UV informs HV that transition of
the guest to secure mode is complete.
These two states (transition to secure mode STARTED and transition
to secure mode COMPLETED) are recorded in kvm->arch.secure_guest.
Setting these states will cause the assembly code that enters the
guest to call the UV_RETURN ucall instead of trying to enter the
guest directly.
Signed-off-by: Bharata B Rao <redacted>
Acked-by: Paul Mackerras <redacted>
---
arch/powerpc/include/asm/hvcall.h | 2 ++
arch/powerpc/include/asm/kvm_book3s_devm.h | 12 ++++++++
arch/powerpc/include/asm/kvm_host.h | 4 +++
arch/powerpc/include/asm/ultravisor-api.h | 1 +
arch/powerpc/include/asm/ultravisor.h | 7 +++++
arch/powerpc/kvm/book3s_hv.c | 7 +++++
arch/powerpc/kvm/book3s_hv_devm.c | 34 ++++++++++++++++++++++
7 files changed, 67 insertions(+)
From: Bharata B Rao <hidden> Date: 2019-08-22 10:26:57
Register the new memslot with UV during plug and unregister
the memslot during unplug.
Signed-off-by: Bharata B Rao <redacted>
Acked-by: Paul Mackerras <redacted>
---
arch/powerpc/include/asm/ultravisor-api.h | 1 +
arch/powerpc/include/asm/ultravisor.h | 5 +++++
arch/powerpc/kvm/book3s_hv.c | 17 +++++++++++++++++
3 files changed, 23 insertions(+)
From: Bharata B Rao <hidden> Date: 2019-08-22 10:26:59
- After the guest becomes secure, when we handle a page fault of a page
belonging to SVM in HV, send that page to UV via UV_PAGE_IN.
- Whenever a page is unmapped on the HV side, inform UV via UV_PAGE_INVAL.
- Ensure all those routines that walk the secondary page tables of
the guest don't do so in case of secure VM. For secure guest, the
active secondary page tables are in secure memory and the secondary
page tables in HV are freed when guest becomes secure.
Signed-off-by: Bharata B Rao <redacted>
---
arch/powerpc/include/asm/kvm_host.h | 12 ++++++++++++
arch/powerpc/include/asm/ultravisor-api.h | 1 +
arch/powerpc/include/asm/ultravisor.h | 5 +++++
arch/powerpc/kvm/book3s_64_mmu_radix.c | 22 ++++++++++++++++++++++
arch/powerpc/kvm/book3s_hv_devm.c | 20 ++++++++++++++++++++
5 files changed, 60 insertions(+)
From: Bharata B Rao <hidden> Date: 2019-08-22 10:27:01
Add support for reset of secure guest via a new ioctl KVM_PPC_SVM_OFF.
This ioctl will be issued by QEMU during reset and includes the
the following steps:
- Ask UV to terminate the guest via UV_SVM_TERMINATE ucall
- Unpin the VPA pages so that they can be migrated back to secure
side when guest becomes secure again. This is required because
pinned pages can't be migrated.
- Reinitialize guest's partitioned scoped page tables. These are
freed when guest becomes secure (H_SVM_INIT_DONE)
- Release all device pages of the secure guest.
After these steps, guest is ready to issue UV_ESM call once again
to switch to secure mode.
Signed-off-by: Bharata B Rao <redacted>
Signed-off-by: Sukadev Bhattiprolu <redacted>
[Implementation of uv_svm_terminate() and its call from
guest shutdown path]
Signed-off-by: Ram Pai <redacted>
[Unpinning of VPA pages]
---
Documentation/virtual/kvm/api.txt | 19 ++++++
arch/powerpc/include/asm/kvm_book3s_devm.h | 6 ++
arch/powerpc/include/asm/kvm_ppc.h | 2 +
arch/powerpc/include/asm/ultravisor-api.h | 1 +
arch/powerpc/include/asm/ultravisor.h | 5 ++
arch/powerpc/kvm/book3s_hv.c | 70 ++++++++++++++++++++++
arch/powerpc/kvm/book3s_hv_devm.c | 60 +++++++++++++++++++
arch/powerpc/kvm/powerpc.c | 12 ++++
include/uapi/linux/kvm.h | 1 +
9 files changed, 176 insertions(+)
@@ -4111,6 +4111,25 @@ Valid values for 'action': #define KVM_PMU_EVENT_ALLOW 0 #define KVM_PMU_EVENT_DENY 1+4.121 KVM_PPC_SVM_OFF++Capability: basic+Architectures: powerpc+Type: vm ioctl+Parameters: none+Returns: 0 on successful completion,+Errors:+ EINVAL: if ultravisor failed to terminate the secure guest+ ENOMEM: if hypervisor failed to allocate new radix page tables for guest++This ioctl is used to turn off the secure mode of the guest or transition+the guest from secure mode to normal mode. This is invoked when the guest+is reset. This has no effect if called for a normal guest.++This ioctl issues an ultravisor call to terminate the secure guest,+unpins the VPA pages, reinitializes guest's partition scoped page+tables and releases all the device pages that are used to track the+secure pages by hypervisor. 5. The kvm_run structure ------------------------
@@ -448,6 +448,23 @@ config PPC_TRANSACTIONAL_MEMhelpSupportuser-modeTransactionalMemoryonPOWERPC.+configPPC_UV+bool"Ultravisor support"+depends onKVM_BOOK3S_HV_POSSIBLE+selectZONE_DEVICE+selectDEV_PAGEMAP_OPS+selectDEVICE_PRIVATE+selectMEMORY_HOTPLUG+selectMEMORY_HOTREMOVE+defaultn+help+ThisoptionparavirtualizesthekerneltoruninPOWERplatformsthat+supportstheProtectedExecutionFacility(PEF).Onsuchplatforms,+theultravisorfirmwarerunsataprivilegelevelabovethe+hypervisor.++Ifunsure,say"N".+configLD_HEAD_STUB_CATCHbool"Reserve 256 bytes to cope with linker stubs in HEAD text"ifEXPERTdepends onPPC64
From: Paul Mackerras <hidden> Date: 2019-08-23 05:32:55
On Thu, Aug 22, 2019 at 03:56:13PM +0530, Bharata B Rao wrote:
Hi,
A pseries guest can be run as a secure guest on Ultravisor-enabled
POWER platforms. On such platforms, this driver will be used to manage
the movement of guest pages between the normal memory managed by
hypervisor(HV) and secure memory managed by Ultravisor(UV).
Private ZONE_DEVICE memory equal to the amount of secure memory
available in the platform for running secure guests is created.
Whenever a page belonging to the guest becomes secure, a page from
this private device memory is used to represent and track that secure
page on the HV side. The movement of pages between normal and secure
memory is done via migrate_vma_pages(). The reverse movement is driven
via pagemap_ops.migrate_to_ram().
The page-in or page-out requests from UV will come to HV as hcalls and
HV will call back into UV via uvcalls to satisfy these page requests.
These patches are against hmm.git
(https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=hmm)
plus
Claudio Carvalho's base ultravisor enablement patchset v6
(https://lore.kernel.org/linuxppc-dev/20190822034838.27876-1-cclaudio@linux.ibm.com/T/#t)
How are you thinking these patches will go upstream? Are you going to
send them via the hmm tree?
I assume you need Claudio's patchset as a prerequisite for your series
to compile, which means the hmm maintainers would need to pull in a
topic branch from Michael Ellerman's powerpc tree, or something like
that.
Paul.
From: Bharata B Rao <hidden> Date: 2019-08-23 06:58:16
On Fri, Aug 23, 2019 at 02:17:47PM +1000, Paul Mackerras wrote:
On Thu, Aug 22, 2019 at 03:56:13PM +0530, Bharata B Rao wrote:
quoted
Hi,
A pseries guest can be run as a secure guest on Ultravisor-enabled
POWER platforms. On such platforms, this driver will be used to manage
the movement of guest pages between the normal memory managed by
hypervisor(HV) and secure memory managed by Ultravisor(UV).
Private ZONE_DEVICE memory equal to the amount of secure memory
available in the platform for running secure guests is created.
Whenever a page belonging to the guest becomes secure, a page from
this private device memory is used to represent and track that secure
page on the HV side. The movement of pages between normal and secure
memory is done via migrate_vma_pages(). The reverse movement is driven
via pagemap_ops.migrate_to_ram().
The page-in or page-out requests from UV will come to HV as hcalls and
HV will call back into UV via uvcalls to satisfy these page requests.
These patches are against hmm.git
(https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=hmm)
plus
Claudio Carvalho's base ultravisor enablement patchset v6
(https://lore.kernel.org/linuxppc-dev/20190822034838.27876-1-cclaudio@linux.ibm.com/T/#t)
How are you thinking these patches will go upstream? Are you going to
send them via the hmm tree?
I assume you need Claudio's patchset as a prerequisite for your series
to compile, which means the hmm maintainers would need to pull in a
topic branch from Michael Ellerman's powerpc tree, or something like
that.
I was hoping that changes required from hmm.git would hit upstream soon,
will reflect in mpe's powerpc tree at which time these patches can go
via powerpc tree along with or after Claudio's patchset.
Though this depends on migrate_vma and memremap changes that
happen to be in hmm.git, this is majorly a kvmppc change. Hence I thought
it would be appropriate for this to go via your or mpe's tree together
with required dependencies.
Regards,
Bharata.
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2019-08-23 11:57:48
Paul Mackerras [off-list ref] writes:
On Thu, Aug 22, 2019 at 03:56:13PM +0530, Bharata B Rao wrote:
quoted
A pseries guest can be run as a secure guest on Ultravisor-enabled
POWER platforms. On such platforms, this driver will be used to manage
the movement of guest pages between the normal memory managed by
hypervisor(HV) and secure memory managed by Ultravisor(UV).
Private ZONE_DEVICE memory equal to the amount of secure memory
available in the platform for running secure guests is created.
Whenever a page belonging to the guest becomes secure, a page from
this private device memory is used to represent and track that secure
page on the HV side. The movement of pages between normal and secure
memory is done via migrate_vma_pages(). The reverse movement is driven
via pagemap_ops.migrate_to_ram().
The page-in or page-out requests from UV will come to HV as hcalls and
HV will call back into UV via uvcalls to satisfy these page requests.
These patches are against hmm.git
(https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/log/?h=hmm)
plus
Claudio Carvalho's base ultravisor enablement patchset v6
(https://lore.kernel.org/linuxppc-dev/20190822034838.27876-1-cclaudio@linux.ibm.com/T/#t)
How are you thinking these patches will go upstream? Are you going to
send them via the hmm tree?
I assume you need Claudio's patchset as a prerequisite for your series
to compile, which means the hmm maintainers would need to pull in a
topic branch from Michael Ellerman's powerpc tree, or something like
that.
I think more workable would be for me to make a topic branch based on
the hmm tree (or some commit from the hmm tree), which I then apply the
patches on top of, and merge any required powerpc changes into that. I
can then ask Linus to merge that branch late in the merge window once
the hmm changes have gone in.
The bigger problem at the moment is the lack of reviews or acks on the
bulk of the series.
cheers
+
+struct kvmppc_devm_page_pvt {
+ unsigned long *rmap;
+ unsigned int lpid;
+ unsigned long gpa;
+};
+
+/*
+ * Get a free device PFN from the pool
+ *
+ * Called when a normal page is moved to secure memory (UV_PAGE_IN). Device
+ * PFN will be used to keep track of the secure page on HV side.
+ *
+ * @rmap here is the slot in the rmap array that corresponds to @gpa.
+ * Thus a non-zero rmap entry indicates that the corresponding guest
+ * page has become secure, and is not mapped on the HV side.
+ *
+ * NOTE: In this and subsequent functions, we pass around and access
+ * individual elements of kvm_memory_slot->arch.rmap[] without any
+ * protection. Should we use lock_rmap() here?
+ */
+static struct page *kvmppc_devm_get_page(unsigned long *rmap, unsigned long gpa,
+ unsigned int lpid)
+{
+ struct page *dpage = NULL;
+ unsigned long bit, devm_pfn;
+ unsigned long flags;
+ struct kvmppc_devm_page_pvt *pvt;
+ unsigned long pfn_last, pfn_first;
+
+ if (kvmppc_rmap_is_devm_pfn(*rmap))
+ return NULL;
+
+ pfn_first = kvmppc_devm_pgmap.res.start >> PAGE_SHIFT;
+ pfn_last = pfn_first +
+ (resource_size(&kvmppc_devm_pgmap.res) >> PAGE_SHIFT);
+ spin_lock_irqsave(&kvmppc_devm_pfn_lock, flags);
Blank lines around spin_lock() would help.
+ bit = find_first_zero_bit(kvmppc_devm_pfn_bitmap, pfn_last - pfn_first);
+ if (bit >= (pfn_last - pfn_first))
+ goto out;
+
+ bitmap_set(kvmppc_devm_pfn_bitmap, bit, 1);
+ devm_pfn = bit + pfn_first;
Can we drop the &kvmppc_devm_pfn_lock here or after the trylock_page()?
Or does it also protect the ->zone_device_data' assignment below as well?
If so, maybe drop the 'pfn_' from the name of the lock?
Besides, we don't seem to hold this lock when accessing ->zone_device_data
in kvmppc_share_page(). Maybe &kvmppc_devm_pfn_lock just protects the bitmap?
+ dpage = pfn_to_page(devm_pfn);
Does this code and hence CONFIG_PPC_UV depend on a specific model like
CONFIG_SPARSEMEM_VMEMMAP?
->zone_device_data is set after locking the dpage here, but in
kvmppc_share_page() and kvmppc_devm_fault_migrate_alloc_and_copy()
it is accessed without locking the page?
+ spin_unlock_irqrestore(&kvmppc_devm_pfn_lock, flags);
+
+ get_page(dpage);
+ return dpage;
+
+out_unlock:
+ unlock_page(dpage);
+out_clear:
+ bitmap_clear(kvmppc_devm_pfn_bitmap, devm_pfn - pfn_first, 1);
+out:
+ spin_unlock_irqrestore(&kvmppc_devm_pfn_lock, flags);
+ return NULL;
+}
+
+/*
+ * Alloc a PFN from private device memory pool and copy page from normal
+ * memory to secure memory.
+ */
+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;
+}
+
+/*
+ * 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;
These are the host frame numbers correct? Trying to distinguish them
from 'gfn' and 'gpa' used in the function.
+ struct migrate_vma mig;
+ struct vm_area_struct *vma;
+ int srcu_idx;
+ unsigned long gfn = gpa >> page_shift;
+ struct kvm_memory_slot *slot;
+ unsigned long *rmap;
+ int ret;
+
+ if (page_shift != PAGE_SHIFT)
+ return H_P3;
+
+ if (flags)
+ return H_P2;
+
+ ret = H_PARAMETER;
+ down_read(&kvm->mm->mmap_sem);
+ srcu_idx = srcu_read_lock(&kvm->srcu);
+ slot = gfn_to_memslot(kvm, gfn);
Use 'gfn' as the second parameter?
Nit. for consistency with gpa and gfn, maybe rename 'addr' to
'hva' or to match 'end' maybe to 'start'.
Also, can we check 'kvmppc_rmap_is_devm_pfn(*rmap)' here and bail out
if its already shared? We currently do it further down the call chain
in kvmppc_devm_get_page() after doing more work.
+ if (kvm_is_error_hva(addr))
+ goto out;
+
+ end = addr + (1UL << page_shift);
+ vma = find_vma_intersection(kvm->mm, addr, end);
+ if (!vma || vma->vm_start > addr || vma->vm_end < end)
+ goto out;
+
+ memset(&mig, 0, sizeof(mig));
+ mig.vma = vma;
+ mig.start = addr;
+ mig.end = end;
+ mig.src = &src_pfn;
+ mig.dst = &dst_pfn;
+
+ if (migrate_vma_setup(&mig))
+ goto out;
+
+ if (kvmppc_devm_migrate_alloc_and_copy(&mig, rmap, gpa,
+ kvm->arch.lpid, page_shift))
+ goto out_finalize;
+
+ migrate_vma_pages(&mig);
+ ret = H_SUCCESS;
+out_finalize:
+ migrate_vma_finalize(&mig);
+out:
+ srcu_read_unlock(&kvm->srcu, srcu_idx);
+ up_read(&kvm->mm->mmap_sem);
+ return ret;
+}
+
+/*
+ * Provision a new page on HV side and copy over the contents
+ * from secure memory.
+ */
+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;
What does it mean if its not a zone_device page at this point? Caller
would then proceed to migrage_vma_pages() if we return 0 right?
+
+ 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;
+}
+
+/*
+ * Fault handler callback when HV touches any page that has been
+ * moved to secure memory, we ask UV to give back the page by
+ * issuing a UV_PAGE_OUT uvcall.
+ *
+ * This eventually results in dropping of device PFN and the newly
+ * provisioned page/PFN gets populated in QEMU page tables.
+ */
+static vm_fault_t kvmppc_devm_migrate_to_ram(struct vm_fault *vmf)
+{
+ unsigned long src_pfn, dst_pfn = 0;
+ struct migrate_vma mig;
+ int ret = 0;
+
+ memset(&mig, 0, sizeof(mig));
+ mig.vma = vmf->vma;
+ mig.start = vmf->address;
+ mig.end = vmf->address + PAGE_SIZE;
+ mig.src = &src_pfn;
+ mig.dst = &dst_pfn;
+
+ if (migrate_vma_setup(&mig)) {
+ ret = VM_FAULT_SIGBUS;
+ goto out;
+ }
+
+ if (kvmppc_devm_fault_migrate_alloc_and_copy(&mig, PAGE_SHIFT)) {
+ ret = VM_FAULT_SIGBUS;
+ goto out_finalize;
+ }
+
+ migrate_vma_pages(&mig);
+out_finalize:
+ migrate_vma_finalize(&mig);
+out:
+ return ret;
+}
+
+/*
+ * Release the device PFN back to the pool
+ *
+ * Gets called when secure page becomes a normal page during UV_PAGE_OUT.
If the pfn_lock only protects the bitmap, would be better to move
it here?
+
+ bitmap_clear(kvmppc_devm_pfn_bitmap,
+ pfn - (kvmppc_devm_pgmap.res.start >> PAGE_SHIFT), 1);
+ *pvt->rmap = 0;
+ spin_unlock_irqrestore(&kvmppc_devm_pfn_lock, flags);
+ kfree(pvt);
+}
+
+static const struct dev_pagemap_ops kvmppc_devm_ops = {
+ .page_free = kvmppc_devm_page_free,
+ .migrate_to_ram = kvmppc_devm_migrate_to_ram,
+};
+
+/*
+ * 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)
+{
+ struct migrate_vma mig;
+ unsigned long addr, end;
+ struct vm_area_struct *vma;
+ unsigned long src_pfn, dst_pfn = 0;
+ int srcu_idx;
+ int ret;
Nit: Not sure its a coding style requirement, but many functions seem
to "sort" these local variables in descending order of line length for
appearance :-) (eg: migrate_vma* functions).
A secure guest will share some of its pages with hypervisor (Eg. virtio
bounce buffers etc). Support sharing of pages between hypervisor and
ultravisor.
Once a secure page is converted to shared page, the device page is
unmapped from the HV side page tables.
Signed-off-by: Bharata B Rao <redacted>
---
arch/powerpc/include/asm/hvcall.h | 3 ++
arch/powerpc/kvm/book3s_hv_devm.c | 70 +++++++++++++++++++++++++++++--
2 files changed, 69 insertions(+), 4 deletions(-)
+ if (is_error_noslot_pfn(pfn))
+ goto out;
+
+ ret = uv_page_in(kvm->arch.lpid, pfn << page_shift, gpa, 0, page_shift);
+ if (ret == U_SUCCESS)
+ ret = H_SUCCESS;
+ kvm_release_pfn_clean(pfn);
Nit: Blank line?
quoted hunk
+out:
+ srcu_read_unlock(&kvm->srcu, srcu_idx);
+ return ret;
+}
+
/*
* Move page from normal memory to secure memory.
*/
@@ -159,9 +208,12 @@ kvmppc_h_svm_page_in(struct kvm *kvm, unsigned long gpa, if (page_shift != PAGE_SHIFT) return H_P3;- if (flags)+ if (flags & ~H_PAGE_IN_SHARED) return H_P2;+ if (flags & H_PAGE_IN_SHARED)+ return kvmppc_share_page(kvm, gpa, page_shift);+ ret = H_PARAMETER; down_read(&kvm->mm->mmap_sem); srcu_idx = srcu_read_lock(&kvm->srcu);
@@ -211,7 +263,7 @@ kvmppc_devm_fault_migrate_alloc_and_copy(struct migrate_vma *mig, struct page *dpage, *spage; struct kvmppc_devm_page_pvt *pvt; unsigned long pfn;- int ret;+ int ret = U_SUCCESS; spage = migrate_pfn_to_page(*mig->src); if (!spage || !(*mig->src & MIGRATE_PFN_MIGRATE))
@@ -226,8 +278,18 @@ kvmppc_devm_fault_migrate_alloc_and_copy(struct migrate_vma *mig, pvt = spage->zone_device_data; pfn = page_to_pfn(dpage);- ret = uv_page_out(pvt->lpid, pfn << page_shift, pvt->gpa, 0,- page_shift);++ /*+ * This same function is used in two cases:
Nit: s/same//
+ * - When HV touches a secure page, for which we do page-out
Better to qualify page-out with "uv page-out"? its kind of counterintuitive
to do a page-out on a fault!
+ * - When a secure page is converted to shared page, we touch
+ * the page to essentially unmap the device page. In this
+ * case we skip page-out.
+ */
+ if (!pvt->skip_page_out)
+ 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 {
--
2.21.0
- After the guest becomes secure, when we handle a page fault of a page
belonging to SVM in HV, send that page to UV via UV_PAGE_IN.
- Whenever a page is unmapped on the HV side, inform UV via UV_PAGE_INVAL.
- Ensure all those routines that walk the secondary page tables of
the guest don't do so in case of secure VM. For secure guest, the
active secondary page tables are in secure memory and the secondary
page tables in HV are freed when guest becomes secure.
Signed-off-by: Bharata B Rao <redacted>
---
arch/powerpc/include/asm/kvm_host.h | 12 ++++++++++++
arch/powerpc/include/asm/ultravisor-api.h | 1 +
arch/powerpc/include/asm/ultravisor.h | 5 +++++
arch/powerpc/kvm/book3s_64_mmu_radix.c | 22 ++++++++++++++++++++++
arch/powerpc/kvm/book3s_hv_devm.c | 20 ++++++++++++++++++++
5 files changed, 60 insertions(+)
+
+struct kvmppc_devm_page_pvt {
+ unsigned long *rmap;
+ unsigned int lpid;
+ unsigned long gpa;
+};
+
+/*
+ * Get a free device PFN from the pool
+ *
+ * Called when a normal page is moved to secure memory (UV_PAGE_IN). Device
+ * PFN will be used to keep track of the secure page on HV side.
+ *
+ * @rmap here is the slot in the rmap array that corresponds to @gpa.
+ * Thus a non-zero rmap entry indicates that the corresponding guest
+ * page has become secure, and is not mapped on the HV side.
+ *
+ * NOTE: In this and subsequent functions, we pass around and access
+ * individual elements of kvm_memory_slot->arch.rmap[] without any
+ * protection. Should we use lock_rmap() here?
+ */
+static struct page *kvmppc_devm_get_page(unsigned long *rmap, unsigned long gpa,
+ unsigned int lpid)
+{
+ struct page *dpage = NULL;
+ unsigned long bit, devm_pfn;
+ unsigned long flags;
+ struct kvmppc_devm_page_pvt *pvt;
+ unsigned long pfn_last, pfn_first;
+
+ if (kvmppc_rmap_is_devm_pfn(*rmap))
+ return NULL;
+
+ pfn_first = kvmppc_devm_pgmap.res.start >> PAGE_SHIFT;
+ pfn_last = pfn_first +
+ (resource_size(&kvmppc_devm_pgmap.res) >> PAGE_SHIFT);
+ spin_lock_irqsave(&kvmppc_devm_pfn_lock, flags);
Blank lines around spin_lock() would help.
You mean blank line before lock and after unlock to clearly see
where the lock starts and ends?
quoted
+ bit = find_first_zero_bit(kvmppc_devm_pfn_bitmap, pfn_last - pfn_first);
+ if (bit >= (pfn_last - pfn_first))
+ goto out;
+
+ bitmap_set(kvmppc_devm_pfn_bitmap, bit, 1);
+ devm_pfn = bit + pfn_first;
Can we drop the &kvmppc_devm_pfn_lock here or after the trylock_page()?
Or does it also protect the ->zone_device_data' assignment below as well?
If so, maybe drop the 'pfn_' from the name of the lock?
Besides, we don't seem to hold this lock when accessing ->zone_device_data
in kvmppc_share_page(). Maybe &kvmppc_devm_pfn_lock just protects the bitmap?
Will move the unlock to appropriately.
quoted
+ dpage = pfn_to_page(devm_pfn);
Does this code and hence CONFIG_PPC_UV depend on a specific model like
CONFIG_SPARSEMEM_VMEMMAP?
I don't think so. Irrespective of that pfn_to_page() should just work
for us.
->zone_device_data is set after locking the dpage here, but in
kvmppc_share_page() and kvmppc_devm_fault_migrate_alloc_and_copy()
it is accessed without locking the page?
quoted
+ spin_unlock_irqrestore(&kvmppc_devm_pfn_lock, flags);
+
+ get_page(dpage);
+ return dpage;
+
+out_unlock:
+ unlock_page(dpage);
+out_clear:
+ bitmap_clear(kvmppc_devm_pfn_bitmap, devm_pfn - pfn_first, 1);
+out:
+ spin_unlock_irqrestore(&kvmppc_devm_pfn_lock, flags);
+ return NULL;
+}
+
+/*
+ * Alloc a PFN from private device memory pool and copy page from normal
+ * memory to secure memory.
+ */
+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;
+}
+
+/*
+ * 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;
These are the host frame numbers correct? Trying to distinguish them
from 'gfn' and 'gpa' used in the function.
Yes host pfns.
quoted
+ struct migrate_vma mig;
+ struct vm_area_struct *vma;
+ int srcu_idx;
+ unsigned long gfn = gpa >> page_shift;
+ struct kvm_memory_slot *slot;
+ unsigned long *rmap;
+ int ret;
+
+ if (page_shift != PAGE_SHIFT)
+ return H_P3;
+
+ if (flags)
+ return H_P2;
+
+ ret = H_PARAMETER;
+ down_read(&kvm->mm->mmap_sem);
+ srcu_idx = srcu_read_lock(&kvm->srcu);
+ slot = gfn_to_memslot(kvm, gfn);
Nit. for consistency with gpa and gfn, maybe rename 'addr' to
'hva' or to match 'end' maybe to 'start'.
Guess using hva improves readability, sure.
Also, can we check 'kvmppc_rmap_is_devm_pfn(*rmap)' here and bail out
if its already shared? We currently do it further down the call chain
in kvmppc_devm_get_page() after doing more work.
If the page is already shared, we just give the same back to UV if
UV indeed asks for it to be re-shared.
That said, I think we can have kvmppc_rmap_is_devm_pfn early in
regular page-in (non-shared case) path so that we don't even setup
anything required for migrate_vma_pages.
quoted
+ if (kvm_is_error_hva(addr))
+ goto out;
+
+ end = addr + (1UL << page_shift);
+ vma = find_vma_intersection(kvm->mm, addr, end);
+ if (!vma || vma->vm_start > addr || vma->vm_end < end)
+ goto out;
+
+ memset(&mig, 0, sizeof(mig));
+ mig.vma = vma;
+ mig.start = addr;
+ mig.end = end;
+ mig.src = &src_pfn;
+ mig.dst = &dst_pfn;
+
+ if (migrate_vma_setup(&mig))
+ goto out;
+
+ if (kvmppc_devm_migrate_alloc_and_copy(&mig, rmap, gpa,
+ kvm->arch.lpid, page_shift))
+ goto out_finalize;
+
+ migrate_vma_pages(&mig);
+ ret = H_SUCCESS;
+out_finalize:
+ migrate_vma_finalize(&mig);
+out:
+ srcu_read_unlock(&kvm->srcu, srcu_idx);
+ up_read(&kvm->mm->mmap_sem);
+ return ret;
+}
+
+/*
+ * Provision a new page on HV side and copy over the contents
+ * from secure memory.
+ */
+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;
What does it mean if its not a zone_device page at this point? Caller
would then proceed to migrage_vma_pages() if we return 0 right?
kvmppc_devm_fault_migrate_alloc_and_copy() can be called from two paths:
1. Fault path when HV touches the secure page. In this case the page
has to be a device page.
2. When page-out is issued for a page that is already paged-in. In this
case also it has be a device page.
For both the above cases, that check is redundant.
There is a 3rd case which is possible. If UV ever issues a page-out
for a shared page, this check will result in page-out hcall silently
succeeding w/o doing any migration (as we don't populate the dst_pfn)
quoted
+
+ 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;
+}
+
+/*
+ * Fault handler callback when HV touches any page that has been
+ * moved to secure memory, we ask UV to give back the page by
+ * issuing a UV_PAGE_OUT uvcall.
+ *
+ * This eventually results in dropping of device PFN and the newly
+ * provisioned page/PFN gets populated in QEMU page tables.
+ */
+static vm_fault_t kvmppc_devm_migrate_to_ram(struct vm_fault *vmf)
+{
+ unsigned long src_pfn, dst_pfn = 0;
+ struct migrate_vma mig;
+ int ret = 0;
+
+ memset(&mig, 0, sizeof(mig));
+ mig.vma = vmf->vma;
+ mig.start = vmf->address;
+ mig.end = vmf->address + PAGE_SIZE;
+ mig.src = &src_pfn;
+ mig.dst = &dst_pfn;
+
+ if (migrate_vma_setup(&mig)) {
+ ret = VM_FAULT_SIGBUS;
+ goto out;
+ }
+
+ if (kvmppc_devm_fault_migrate_alloc_and_copy(&mig, PAGE_SHIFT)) {
+ ret = VM_FAULT_SIGBUS;
+ goto out_finalize;
+ }
+
+ migrate_vma_pages(&mig);
+out_finalize:
+ migrate_vma_finalize(&mig);
+out:
+ return ret;
+}
+
+/*
+ * Release the device PFN back to the pool
+ *
+ * Gets called when secure page becomes a normal page during UV_PAGE_OUT.
If the pfn_lock only protects the bitmap, would be better to move
it here?
Yes.
quoted
+
+ bitmap_clear(kvmppc_devm_pfn_bitmap,
+ pfn - (kvmppc_devm_pgmap.res.start >> PAGE_SHIFT), 1);
+ *pvt->rmap = 0;
+ spin_unlock_irqrestore(&kvmppc_devm_pfn_lock, flags);
+ kfree(pvt);
+}
+
+static const struct dev_pagemap_ops kvmppc_devm_ops = {
+ .page_free = kvmppc_devm_page_free,
+ .migrate_to_ram = kvmppc_devm_migrate_to_ram,
+};
+
+/*
+ * 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)
+{
+ struct migrate_vma mig;
+ unsigned long addr, end;
+ struct vm_area_struct *vma;
+ unsigned long src_pfn, dst_pfn = 0;
+ int srcu_idx;
+ int ret;
Nit: Not sure its a coding style requirement, but many functions seem
to "sort" these local variables in descending order of line length for
appearance :-) (eg: migrate_vma* functions).
It has ended up like this over multiple versions when variables got added,
moved and re-added.
With a blank like above the label line (which is blank for the most part),
it looks a bit too much of blank to me :)
However I do have blank line at a few other places. I have been removing
them whenever I touch the surrounding lines.
Thanks for your review.
Christoph - You did review this patch in the last iteration. Do you have
any additional comments?
Regards,
Bharata.
From: Bharata B Rao <hidden> Date: 2019-08-29 06:58:23
On Wed, Aug 28, 2019 at 08:04:43PM -0700, Sukadev Bhattiprolu wrote:
quoted
A secure guest will share some of its pages with hypervisor (Eg. virtio
bounce buffers etc). Support sharing of pages between hypervisor and
ultravisor.
Once a secure page is converted to shared page, the device page is
unmapped from the HV side page tables.
Signed-off-by: Bharata B Rao <redacted>
---
arch/powerpc/include/asm/hvcall.h | 3 ++
arch/powerpc/kvm/book3s_hv_devm.c | 70 +++++++++++++++++++++++++++++--
2 files changed, 69 insertions(+), 4 deletions(-)
+ if (is_error_noslot_pfn(pfn))
+ goto out;
+
+ ret = uv_page_in(kvm->arch.lpid, pfn << page_shift, gpa, 0, page_shift);
+ if (ret == U_SUCCESS)
+ ret = H_SUCCESS;
+ kvm_release_pfn_clean(pfn);
Nit: Blank line?
quoted
+out:
+ srcu_read_unlock(&kvm->srcu, srcu_idx);
+ return ret;
+}
+
/*
* Move page from normal memory to secure memory.
*/
@@ -159,9 +208,12 @@ kvmppc_h_svm_page_in(struct kvm *kvm, unsigned long gpa, if (page_shift != PAGE_SHIFT) return H_P3;- if (flags)+ if (flags & ~H_PAGE_IN_SHARED) return H_P2;+ if (flags & H_PAGE_IN_SHARED)+ return kvmppc_share_page(kvm, gpa, page_shift);+ ret = H_PARAMETER; down_read(&kvm->mm->mmap_sem); srcu_idx = srcu_read_lock(&kvm->srcu);
@@ -211,7 +263,7 @@ kvmppc_devm_fault_migrate_alloc_and_copy(struct migrate_vma *mig, struct page *dpage, *spage; struct kvmppc_devm_page_pvt *pvt; unsigned long pfn;- int ret;+ int ret = U_SUCCESS; spage = migrate_pfn_to_page(*mig->src); if (!spage || !(*mig->src & MIGRATE_PFN_MIGRATE))
@@ -226,8 +278,18 @@ kvmppc_devm_fault_migrate_alloc_and_copy(struct migrate_vma *mig, pvt = spage->zone_device_data; pfn = page_to_pfn(dpage);- ret = uv_page_out(pvt->lpid, pfn << page_shift, pvt->gpa, 0,- page_shift);++ /*+ * This same function is used in two cases:
Nit: s/same//
Extra emphasis :)
quoted
+ * - When HV touches a secure page, for which we do page-out
Better to qualify page-out with "uv page-out"? its kind of counterintuitive
to do a page-out on a fault!
From: Bharata B Rao <hidden> Date: 2019-08-29 07:58:03
On Wed, Aug 28, 2019 at 08:05:52PM -0700, Sukadev Bhattiprolu wrote:
quoted
- After the guest becomes secure, when we handle a page fault of a page
belonging to SVM in HV, send that page to UV via UV_PAGE_IN.
- Whenever a page is unmapped on the HV side, inform UV via UV_PAGE_INVAL.
- Ensure all those routines that walk the secondary page tables of
the guest don't do so in case of secure VM. For secure guest, the
active secondary page tables are in secure memory and the secondary
page tables in HV are freed when guest becomes secure.
Signed-off-by: Bharata B Rao <redacted>
---
arch/powerpc/include/asm/kvm_host.h | 12 ++++++++++++
arch/powerpc/include/asm/ultravisor-api.h | 1 +
arch/powerpc/include/asm/ultravisor.h | 5 +++++
arch/powerpc/kvm/book3s_64_mmu_radix.c | 22 ++++++++++++++++++++++
arch/powerpc/kvm/book3s_hv_devm.c | 20 ++++++++++++++++++++
5 files changed, 60 insertions(+)
From: Christoph Hellwig <hch@lst.de> Date: 2019-08-29 08:38:16
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)
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.
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);
+
+struct kvmppc_devm_page_pvt {
+ unsigned long *rmap;
+ unsigned int lpid;
+ unsigned long gpa;
+};
+
+/*
+ * Get a free device PFN from the pool
+ *
+ * Called when a normal page is moved to secure memory (UV_PAGE_IN). Device
+ * PFN will be used to keep track of the secure page on HV side.
+ *
+ * @rmap here is the slot in the rmap array that corresponds to @gpa.
+ * Thus a non-zero rmap entry indicates that the corresponding guest
+ * page has become secure, and is not mapped on the HV side.
+ *
+ * NOTE: In this and subsequent functions, we pass around and access
+ * individual elements of kvm_memory_slot->arch.rmap[] without any
+ * protection. Should we use lock_rmap() here?
Where do we serialize two threads attempting to H_SVM_PAGE_IN the same gfn
at the same time? Or one thread issuing a H_SVM_PAGE_IN and another a
H_SVM_PAGE_OUT for the same page?
quoted
quoted
+ */
+static struct page *kvmppc_devm_get_page(unsigned long *rmap, unsigned long gpa,
+ unsigned int lpid)
+{
+ struct page *dpage = NULL;
+ unsigned long bit, devm_pfn;
+ unsigned long flags;
+ struct kvmppc_devm_page_pvt *pvt;
+ unsigned long pfn_last, pfn_first;
+
+ if (kvmppc_rmap_is_devm_pfn(*rmap))
+ return NULL;
+
+ pfn_first = kvmppc_devm_pgmap.res.start >> PAGE_SHIFT;
+ pfn_last = pfn_first +
+ (resource_size(&kvmppc_devm_pgmap.res) >> PAGE_SHIFT);
+ spin_lock_irqsave(&kvmppc_devm_pfn_lock, flags);
Blank lines around spin_lock() would help.
You mean blank line before lock and after unlock to clearly see
where the lock starts and ends?
quoted
quoted
+ bit = find_first_zero_bit(kvmppc_devm_pfn_bitmap, pfn_last - pfn_first);
+ if (bit >= (pfn_last - pfn_first))
+ goto out;
+
+ bitmap_set(kvmppc_devm_pfn_bitmap, bit, 1);
+ devm_pfn = bit + pfn_first;
Can we drop the &kvmppc_devm_pfn_lock here or after the trylock_page()?
Or does it also protect the ->zone_device_data' assignment below as well?
If so, maybe drop the 'pfn_' from the name of the lock?
Besides, we don't seem to hold this lock when accessing ->zone_device_data
in kvmppc_share_page(). Maybe &kvmppc_devm_pfn_lock just protects the bitmap?
Will move the unlock to appropriately.
quoted
quoted
+ dpage = pfn_to_page(devm_pfn);
Does this code and hence CONFIG_PPC_UV depend on a specific model like
CONFIG_SPARSEMEM_VMEMMAP?
I don't think so. Irrespective of that pfn_to_page() should just work
for us.
If we fail to alloc, we don't clear the KVMPPC_RMAP_DEVM_PFN?
Also, when/where do we clear this flag on an uv-page-out?
kvmppc_devm_drop_pages() drops the flag on a local variable but not
in the rmap? If we don't clear the flag on page-out, would the
subsequent H_SVM_PAGE_IN of this page fail?
->zone_device_data is set after locking the dpage here, but in
kvmppc_share_page() and kvmppc_devm_fault_migrate_alloc_and_copy()
it is accessed without locking the page?
quoted
+ spin_unlock_irqrestore(&kvmppc_devm_pfn_lock, flags);
+
+ get_page(dpage);
+ return dpage;
+
+out_unlock:
+ unlock_page(dpage);
+out_clear:
+ bitmap_clear(kvmppc_devm_pfn_bitmap, devm_pfn - pfn_first, 1);
+out:
+ spin_unlock_irqrestore(&kvmppc_devm_pfn_lock, flags);
+ return NULL;
+}
+
+/*
+ * Alloc a PFN from private device memory pool and copy page from normal
+ * memory to secure memory.
+ */
+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;
+}
+
+/*
+ * 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;
These are the host frame numbers correct? Trying to distinguish them
from 'gfn' and 'gpa' used in the function.
Yes host pfns.
quoted
quoted
+ struct migrate_vma mig;
+ struct vm_area_struct *vma;
+ int srcu_idx;
+ unsigned long gfn = gpa >> page_shift;
+ struct kvm_memory_slot *slot;
+ unsigned long *rmap;
+ int ret;
+
+ if (page_shift != PAGE_SHIFT)
+ return H_P3;
+
+ if (flags)
+ return H_P2;
+
+ ret = H_PARAMETER;
+ down_read(&kvm->mm->mmap_sem);
+ srcu_idx = srcu_read_lock(&kvm->srcu);
+ slot = gfn_to_memslot(kvm, gfn);
Nit. for consistency with gpa and gfn, maybe rename 'addr' to
'hva' or to match 'end' maybe to 'start'.
Guess using hva improves readability, sure.
quoted
Also, can we check 'kvmppc_rmap_is_devm_pfn(*rmap)' here and bail out
if its already shared? We currently do it further down the call chain
in kvmppc_devm_get_page() after doing more work.
If the page is already shared, we just give the same back to UV if
UV indeed asks for it to be re-shared.
That said, I think we can have kvmppc_rmap_is_devm_pfn early in
regular page-in (non-shared case) path so that we don't even setup
anything required for migrate_vma_pages.
quoted
quoted
+ if (kvm_is_error_hva(addr))
+ goto out;
+
+ end = addr + (1UL << page_shift);
+ vma = find_vma_intersection(kvm->mm, addr, end);
+ if (!vma || vma->vm_start > addr || vma->vm_end < end)
+ goto out;
+
+ memset(&mig, 0, sizeof(mig));
+ mig.vma = vma;
+ mig.start = addr;
+ mig.end = end;
+ mig.src = &src_pfn;
+ mig.dst = &dst_pfn;
+
+ if (migrate_vma_setup(&mig))
+ goto out;
+
+ if (kvmppc_devm_migrate_alloc_and_copy(&mig, rmap, gpa,
+ kvm->arch.lpid, page_shift))
+ goto out_finalize;
+
+ migrate_vma_pages(&mig);
+ ret = H_SUCCESS;
+out_finalize:
+ migrate_vma_finalize(&mig);
+out:
+ srcu_read_unlock(&kvm->srcu, srcu_idx);
+ up_read(&kvm->mm->mmap_sem);
+ return ret;
+}
+
+/*
+ * Provision a new page on HV side and copy over the contents
+ * from secure memory.
+ */
+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;
What does it mean if its not a zone_device page at this point? Caller
would then proceed to migrage_vma_pages() if we return 0 right?
kvmppc_devm_fault_migrate_alloc_and_copy() can be called from two paths:
1. Fault path when HV touches the secure page. In this case the page
has to be a device page.
2. When page-out is issued for a page that is already paged-in. In this
case also it has be a device page.
For both the above cases, that check is redundant.
There is a 3rd case which is possible. If UV ever issues a page-out
for a shared page, this check will result in page-out hcall silently
succeeding w/o doing any migration (as we don't populate the dst_pfn)
Ok. Nit. thought we can drop the "_fault" in the function name but would
collide the other "alloc_and_copy" function used during H_SVM_PAGE_IN.
If the two alloc_and_copy functions are symmetric, maybe they could
have "page_in" and "page_out" in the (already long) names.
quoted
quoted
+
+ 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;
+}
+
+/*
+ * Fault handler callback when HV touches any page that has been
+ * moved to secure memory, we ask UV to give back the page by
+ * issuing a UV_PAGE_OUT uvcall.
+ *
+ * This eventually results in dropping of device PFN and the newly
+ * provisioned page/PFN gets populated in QEMU page tables.
+ */
+static vm_fault_t kvmppc_devm_migrate_to_ram(struct vm_fault *vmf)
+{
+ unsigned long src_pfn, dst_pfn = 0;
+ struct migrate_vma mig;
+ int ret = 0;
+
+ memset(&mig, 0, sizeof(mig));
+ mig.vma = vmf->vma;
+ mig.start = vmf->address;
+ mig.end = vmf->address + PAGE_SIZE;
+ mig.src = &src_pfn;
+ mig.dst = &dst_pfn;
+
+ if (migrate_vma_setup(&mig)) {
+ ret = VM_FAULT_SIGBUS;
+ goto out;
+ }
+
+ if (kvmppc_devm_fault_migrate_alloc_and_copy(&mig, PAGE_SHIFT)) {
+ ret = VM_FAULT_SIGBUS;
+ goto out_finalize;
+ }
+
+ migrate_vma_pages(&mig);
+out_finalize:
+ migrate_vma_finalize(&mig);
+out:
+ return ret;
+}
+
+/*
+ * Release the device PFN back to the pool
+ *
+ * Gets called when secure page becomes a normal page during UV_PAGE_OUT.
If the pfn_lock only protects the bitmap, would be better to move
it here?
Yes.
quoted
quoted
+
+ bitmap_clear(kvmppc_devm_pfn_bitmap,
+ pfn - (kvmppc_devm_pgmap.res.start >> PAGE_SHIFT), 1);
+ *pvt->rmap = 0;
+ spin_unlock_irqrestore(&kvmppc_devm_pfn_lock, flags);
+ kfree(pvt);
+}
+
+static const struct dev_pagemap_ops kvmppc_devm_ops = {
+ .page_free = kvmppc_devm_page_free,
+ .migrate_to_ram = kvmppc_devm_migrate_to_ram,
+};
+
+/*
+ * 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)
+{
+ struct migrate_vma mig;
+ unsigned long addr, end;
+ struct vm_area_struct *vma;
+ unsigned long src_pfn, dst_pfn = 0;
+ int srcu_idx;
+ int ret;
Nit: Not sure its a coding style requirement, but many functions seem
to "sort" these local variables in descending order of line length for
appearance :-) (eg: migrate_vma* functions).
It has ended up like this over multiple versions when variables got added,
moved and re-added.
With a blank like above the label line (which is blank for the most part),
it looks a bit too much of blank to me :)
However I do have blank line at a few other places. I have been removing
them whenever I touch the surrounding lines.
Thanks for your review.
Christoph - You did review this patch in the last iteration. Do you have
any additional comments?
Regards,
Bharata.
From: Bharata B Rao <hidden> Date: 2019-08-30 03:43:16
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:
quoted
+/*
+ * 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)
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_
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);
From: Bharata B Rao <hidden> Date: 2019-08-30 11:13:45
On Thu, Aug 29, 2019 at 12:39:11PM -0700, Sukadev Bhattiprolu wrote:
Bharata B Rao [bharata@linux.ibm.com] wrote:
quoted
On Wed, Aug 28, 2019 at 08:02:19PM -0700, Sukadev Bhattiprolu wrote:
Where do we serialize two threads attempting to H_SVM_PAGE_IN the same gfn
at the same time? Or one thread issuing a H_SVM_PAGE_IN and another a
H_SVM_PAGE_OUT for the same page?
I am not not serializing page-in/out calls on same gfn, I thought you take
care of that in UV, guess UV doesn't yet.
I can probably use rmap_lock() and serialize such calls in HV if UV can't
prevent such calls easily.
If we fail to alloc, we don't clear the KVMPPC_RMAP_DEVM_PFN?
Right, I will move the assignment to *rmap to after kzalloc.
Also, when/where do we clear this flag on an uv-page-out?
kvmppc_devm_drop_pages() drops the flag on a local variable but not
in the rmap? If we don't clear the flag on page-out, would the
subsequent H_SVM_PAGE_IN of this page fail?
It gets cleared in kvmppc_devm_page_free().
Ok. Nit. thought we can drop the "_fault" in the function name but would
collide the other "alloc_and_copy" function used during H_SVM_PAGE_IN.
If the two alloc_and_copy functions are symmetric, maybe they could
have "page_in" and "page_out" in the (already long) names.
Christoph also suggested to reorganize these two calls. Will take care.
Regards,
Bharata.
From: Christoph Hellwig <hch@lst.de> Date: 2019-09-02 07:54:02
On Fri, Aug 30, 2019 at 09:12:59AM +0530, Bharata B Rao wrote:
On Thu, Aug 29, 2019 at 10:38:10AM +0200, Christoph Hellwig wrote:
quoted
On Thu, Aug 22, 2019 at 03:56:14PM +0530, Bharata B Rao wrote:
quoted
+/*
+ * 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)
Shouldn't all these defintions go in together in a patch? Also is bi
t 56+ a set of values, so is there 1 << 56 and 3 << 56 as well? Seems
like even that other patch doesn't fully define these "pfn" values.
quoted
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.
Please drop them all. Having to wade through a header to check for
a specific bit that also is set manually elsewhere in related code
just obsfucates it for the reader.
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.
Not really. It just fits the old calling conventions before I removed
the indirection.
quoted
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.
I don't think alloc_and_copy is very helpful. It matches some of the
implementation, but not the intent. Why not kvmppc_svm_page_in/out
similar to the hypervisor calls calling them? Yes, for one case it
also gets called from the pagefault handler, but it still performs
these basic page in/out actions.
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_
From: Bharata B Rao <hidden> Date: 2019-09-06 11:36:52
On Mon, Sep 02, 2019 at 09:53:56AM +0200, Christoph Hellwig wrote:
On Fri, Aug 30, 2019 at 09:12:59AM +0530, Bharata B Rao wrote:
quoted
On Thu, Aug 29, 2019 at 10:38:10AM +0200, Christoph Hellwig wrote:
quoted
On Thu, Aug 22, 2019 at 03:56:14PM +0530, Bharata B Rao wrote:
quoted
+/*
+ * 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)
Shouldn't all these defintions go in together in a patch?
Ideally yes, but the above patch is already in Paul's tree, I will sync
up with him about this.
Also is bit 56+ a set of values, so is there 1 << 56 and 3 << 56 as well? Seems
like even that other patch doesn't fully define these "pfn" values.
I realized that the bit numbers have changed, it is no longer bits 60:56,
but instead top 8bits.
#define KVMPPC_RMAP_UVMEM_PFN 0x0200000000000000
static inline bool kvmppc_rmap_is_uvmem_pfn(unsigned long *rmap)
{
return ((*rmap & 0xff00000000000000) == KVMPPC_RMAP_UVMEM_PFN);
}
quoted
quoted
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.
Please drop them all. Having to wade through a header to check for
a specific bit that also is set manually elsewhere in related code
just obsfucates it for the reader.
I am currently using the routine kvmppc_rmap_is_uvmem_pfn() (shown
above) instead open coding it at multiple places, but I can drop it if
you prefer.
Regards,
Bharata.
From: Christoph Hellwig <hch@lst.de> Date: 2019-09-06 16:32:48
On Fri, Sep 06, 2019 at 05:06:39PM +0530, Bharata B Rao wrote:
quoted
Also is bit 56+ a set of values, so is there 1 << 56 and 3 << 56 as well? Seems
like even that other patch doesn't fully define these "pfn" values.
I realized that the bit numbers have changed, it is no longer bits 60:56,
but instead top 8bits.
#define KVMPPC_RMAP_UVMEM_PFN 0x0200000000000000
static inline bool kvmppc_rmap_is_uvmem_pfn(unsigned long *rmap)
{
return ((*rmap & 0xff00000000000000) == KVMPPC_RMAP_UVMEM_PFN);
}
In that overall scheme I'd actually much prefer something like (names
just made up, they should vaguely match the spec this written to):
static inline unsigned long kvmppc_rmap_type(unsigned long *rmap)
{
return (rmap & 0xff00000000000000);
}
And then where you check it you can use:
if (kvmppc_rmap_type(*rmap) == KVMPPC_RMAP_UVMEM_PFN)
and where you set it you do:
*rmap |= KVMPPC_RMAP_UVMEM_PFN;
as in the current patch to keep things symmetric.