* [PATCH 0/8] Mac ADB IOP driver fixes
From: Finn Thain @ 2020-05-30 23:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Geert Uytterhoeven, linux-m68k, linuxppc-dev, linux-kernel,
Joshua Thompson
The adb-iop driver was never finished. Some deficiencies have become
apparent over the years. For example,
- Mouse and/or keyboard may stop working if used together
- SRQ autopoll list cannot be changed
- Some bugs were found by inspection
This patch series contains fixes for the known bugs in the driver, plus
a few clean-ups.
Finn Thain (8):
macintosh/adb-iop: Remove dead and redundant code
macintosh/adb-iop: Correct comment text
macintosh/adb-iop: Adopt bus reset algorithm from via-macii driver
macintosh/adb-iop: Access current_req and adb_iop_state when inside
lock
macintosh/adb-iop: Resolve static checker warnings
macintosh/adb-iop: Implement idle -> sending state transition
macintosh/adb-iop: Implement sending -> idle state transition
macintosh/adb-iop: Implement SRQ autopolling
arch/m68k/include/asm/adb_iop.h | 1 +
drivers/macintosh/adb-iop.c | 186 +++++++++++++++-----------------
2 files changed, 86 insertions(+), 101 deletions(-)
--
2.26.2
^ permalink raw reply
* [PATCH 6/8] macintosh/adb-iop: Implement idle -> sending state transition
From: Finn Thain @ 2020-05-30 23:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-m68k, linuxppc-dev, linux-kernel, Joshua Thompson
In-Reply-To: <cover.1590880623.git.fthain@telegraphics.com.au>
In the present algorithm, the 'idle' state transition does not take
place until there's a bus timeout. Once idle, the driver does not
automatically proceed with the next request.
Change the algorithm so that queued ADB requests will be sent as soon as
the driver becomes idle. This is to take place after the current IOP
message is completed.
Cc: Joshua Thompson <funaho@jurai.org>
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
drivers/macintosh/adb-iop.c | 43 +++++++++++++++++++++----------------
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git a/drivers/macintosh/adb-iop.c b/drivers/macintosh/adb-iop.c
index a2b28e09f2ce..f22792c95d4f 100644
--- a/drivers/macintosh/adb-iop.c
+++ b/drivers/macintosh/adb-iop.c
@@ -54,13 +54,19 @@ struct adb_driver adb_iop_driver = {
.reset_bus = adb_iop_reset_bus
};
-static void adb_iop_end_req(struct adb_request *req, int state)
+static void adb_iop_done(void)
{
+ struct adb_request *req = current_req;
+
+ adb_iop_state = idle;
+
req->complete = 1;
current_req = req->next;
if (req->done)
(*req->done)(req);
- adb_iop_state = state;
+
+ if (adb_iop_state == idle)
+ adb_iop_start();
}
/*
@@ -94,37 +100,36 @@ static void adb_iop_complete(struct iop_msg *msg)
static void adb_iop_listen(struct iop_msg *msg)
{
struct adb_iopmsg *amsg = (struct adb_iopmsg *)msg->message;
- struct adb_request *req;
unsigned long flags;
+ bool req_done = false;
local_irq_save(flags);
- req = current_req;
-
/* Handle a timeout. Timeout packets seem to occur even after
* we've gotten a valid reply to a TALK, presumably because of
* autopolling.
*/
- if (amsg->flags & ADB_IOP_TIMEOUT) {
- msg->reply[0] = ADB_IOP_TIMEOUT | ADB_IOP_AUTOPOLL;
- msg->reply[1] = 0;
- msg->reply[2] = 0;
- if (req && (adb_iop_state != idle)) {
- adb_iop_end_req(req, idle);
- }
- } else {
- if ((adb_iop_state == awaiting_reply) &&
- (amsg->flags & ADB_IOP_EXPLICIT)) {
+ if (amsg->flags & ADB_IOP_EXPLICIT) {
+ if (adb_iop_state == awaiting_reply) {
+ struct adb_request *req = current_req;
+
req->reply_len = amsg->count + 1;
memcpy(req->reply, &amsg->cmd, req->reply_len);
- } else {
- adb_input(&amsg->cmd, amsg->count + 1,
- amsg->flags & ADB_IOP_AUTOPOLL);
+
+ req_done = true;
}
- memcpy(msg->reply, msg->message, IOP_MSG_LEN);
+ } else if (!(amsg->flags & ADB_IOP_TIMEOUT)) {
+ adb_input(&amsg->cmd, amsg->count + 1,
+ amsg->flags & ADB_IOP_AUTOPOLL);
}
+
+ msg->reply[0] = ADB_IOP_AUTOPOLL;
iop_complete_message(msg);
+
+ if (req_done)
+ adb_iop_done();
+
local_irq_restore(flags);
}
--
2.26.2
^ permalink raw reply related
* [PATCH 8/8] macintosh/adb-iop: Implement SRQ autopolling
From: Finn Thain @ 2020-05-30 23:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-m68k, Geert Uytterhoeven, linux-kernel,
Joshua Thompson
In-Reply-To: <cover.1590880623.git.fthain@telegraphics.com.au>
The adb_driver.autopoll method is needed during ADB bus scan and device
address assignment. Implement this method so that the IOP's list of
device addresses can be updated. When the list is empty, disable SRQ
autopolling.
Cc: Joshua Thompson <funaho@jurai.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
---
arch/m68k/include/asm/adb_iop.h | 1 +
drivers/macintosh/adb-iop.c | 32 ++++++++++++++++++++++++++------
2 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/arch/m68k/include/asm/adb_iop.h b/arch/m68k/include/asm/adb_iop.h
index 195d7fb1268c..6aecd020e2fc 100644
--- a/arch/m68k/include/asm/adb_iop.h
+++ b/arch/m68k/include/asm/adb_iop.h
@@ -29,6 +29,7 @@
#define ADB_IOP_EXPLICIT 0x80 /* nonzero if explicit command */
#define ADB_IOP_AUTOPOLL 0x40 /* auto/SRQ polling enabled */
+#define ADB_IOP_SET_AUTOPOLL 0x20 /* set autopoll device list */
#define ADB_IOP_SRQ 0x04 /* SRQ detected */
#define ADB_IOP_TIMEOUT 0x02 /* nonzero if timeout */
diff --git a/drivers/macintosh/adb-iop.c b/drivers/macintosh/adb-iop.c
index 8594e4f9a830..f3d1a460fbce 100644
--- a/drivers/macintosh/adb-iop.c
+++ b/drivers/macintosh/adb-iop.c
@@ -7,10 +7,6 @@
* 1999-07-01 (jmt) - First implementation for new driver architecture.
*
* 1999-07-31 (jmt) - First working version.
- *
- * TODO:
- *
- * o Implement SRQ handling.
*/
#include <linux/types.h>
@@ -28,6 +24,7 @@
static struct adb_request *current_req;
static struct adb_request *last_req;
+static unsigned int autopoll_devs;
static enum adb_iop_state {
idle,
@@ -123,7 +120,7 @@ static void adb_iop_listen(struct iop_msg *msg)
amsg->flags & ADB_IOP_AUTOPOLL);
}
- msg->reply[0] = ADB_IOP_AUTOPOLL;
+ msg->reply[0] = autopoll_devs ? ADB_IOP_AUTOPOLL : 0;
iop_complete_message(msg);
if (req_done)
@@ -231,9 +228,32 @@ static int adb_iop_write(struct adb_request *req)
return 0;
}
+static void adb_iop_set_ap_complete(struct iop_msg *msg)
+{
+ struct adb_iopmsg *amsg = (struct adb_iopmsg *)msg->message;
+
+ autopoll_devs = (amsg->data[1] << 8) | amsg->data[0];
+}
+
static int adb_iop_autopoll(int devs)
{
- /* TODO: how do we enable/disable autopoll? */
+ struct adb_iopmsg amsg;
+ unsigned long flags;
+ unsigned int mask = (unsigned int)devs & 0xFFFE;
+
+ local_irq_save(flags);
+
+ amsg.flags = ADB_IOP_SET_AUTOPOLL | (mask ? ADB_IOP_AUTOPOLL : 0);
+ amsg.count = 2;
+ amsg.cmd = 0;
+ amsg.data[0] = mask & 0xFF;
+ amsg.data[1] = (mask >> 8) & 0xFF;
+
+ iop_send_message(ADB_IOP, ADB_CHAN, NULL, sizeof(amsg), (__u8 *)&amsg,
+ adb_iop_set_ap_complete);
+
+ local_irq_restore(flags);
+
return 0;
}
--
2.26.2
^ permalink raw reply related
* [PATCH v1 4/4] KVM: PPC: Book3S HV: migrate hot plugged memory
From: Ram Pai @ 2020-05-31 2:27 UTC (permalink / raw)
To: kvm-ppc, linuxppc-dev
Cc: ldufour, linuxram, cclaudio, bharata, aneesh.kumar, sukadev,
bauerman, david
In-Reply-To: <1590892071-25549-1-git-send-email-linuxram@us.ibm.com>
From: Laurent Dufour <ldufour@linux.ibm.com>
When a memory slot is hot plugged to a SVM, GFNs associated with that
memory slot automatically default to secure GFN. Hence migrate the
PFNs associated with these GFNs to device-PFNs.
uv_migrate_mem_slot() is called to achieve that. It will not call
UV_PAGE_IN since this request is ignored by the Ultravisor.
NOTE: Ultravisor does not trust any page content provided by
the Hypervisor, ones the VM turns secure.
Cc: Paul Mackerras <paulus@ozlabs.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Bharata B Rao <bharata@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Laurent Dufour <ldufour@linux.ibm.com>
Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Claudio Carvalho <cclaudio@linux.ibm.com>
Cc: kvm-ppc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
(fixed merge conflicts. Modified the commit message)
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
---
arch/powerpc/include/asm/kvm_book3s_uvmem.h | 4 ++++
arch/powerpc/kvm/book3s_hv.c | 11 +++++++----
arch/powerpc/kvm/book3s_hv_uvmem.c | 3 +--
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s_uvmem.h b/arch/powerpc/include/asm/kvm_book3s_uvmem.h
index f0c5708..2ec2e5afb 100644
--- a/arch/powerpc/include/asm/kvm_book3s_uvmem.h
+++ b/arch/powerpc/include/asm/kvm_book3s_uvmem.h
@@ -23,6 +23,7 @@ unsigned long kvmppc_h_svm_page_out(struct kvm *kvm,
void kvmppc_uvmem_drop_pages(const struct kvm_memory_slot *free,
struct kvm *kvm, bool skip_page_out,
bool purge_gfn);
+int uv_migrate_mem_slot(struct kvm *kvm, const struct kvm_memory_slot *memslot);
#else
static inline int kvmppc_uvmem_init(void)
{
@@ -78,5 +79,8 @@ static inline int kvmppc_send_page_to_uv(struct kvm *kvm, unsigned long gfn)
kvmppc_uvmem_drop_pages(const struct kvm_memory_slot *free,
struct kvm *kvm, bool skip_page_out,
bool purge_gfn) { }
+
+static int uv_migrate_mem_slot(struct kvm *kvm,
+ const struct kvm_memory_slot *memslot);
#endif /* CONFIG_PPC_UV */
#endif /* __ASM_KVM_BOOK3S_UVMEM_H__ */
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 4c62bfe..604d062 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4516,13 +4516,16 @@ static void kvmppc_core_commit_memory_region_hv(struct kvm *kvm,
case KVM_MR_CREATE:
if (kvmppc_uvmem_slot_init(kvm, new))
return;
- uv_register_mem_slot(kvm->arch.lpid,
- new->base_gfn << PAGE_SHIFT,
- new->npages * PAGE_SIZE,
- 0, new->id);
+ if (uv_register_mem_slot(kvm->arch.lpid,
+ new->base_gfn << PAGE_SHIFT,
+ new->npages * PAGE_SIZE,
+ 0, new->id))
+ return;
+ uv_migrate_mem_slot(kvm, new);
break;
case KVM_MR_DELETE:
uv_unregister_mem_slot(kvm->arch.lpid, old->id);
+ kvmppc_uvmem_drop_pages(old, kvm, true, true);
kvmppc_uvmem_slot_free(kvm, old);
break;
default:
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c
index 36dda1d..1fa5f2a 100644
--- a/arch/powerpc/kvm/book3s_hv_uvmem.c
+++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
@@ -377,8 +377,7 @@ static int kvmppc_svm_migrate_page(struct vm_area_struct *vma,
return ret;
}
-static int uv_migrate_mem_slot(struct kvm *kvm,
- const struct kvm_memory_slot *memslot)
+int uv_migrate_mem_slot(struct kvm *kvm, const struct kvm_memory_slot *memslot)
{
unsigned long gfn = memslot->base_gfn;
unsigned long end;
--
1.8.3.1
^ permalink raw reply related
* [PATCH v1 3/4] KVM: PPC: Book3S HV: migrate remaining normal-GFNs to secure-GFNs in H_SVM_INIT_DONE
From: Ram Pai @ 2020-05-31 2:27 UTC (permalink / raw)
To: kvm-ppc, linuxppc-dev
Cc: ldufour, linuxram, cclaudio, bharata, aneesh.kumar, sukadev,
bauerman, david
In-Reply-To: <1590892071-25549-1-git-send-email-linuxram@us.ibm.com>
H_SVM_INIT_DONE incorrectly assumes that the Ultravisor has explicitly
called H_SVM_PAGE_IN for all secure pages. These GFNs continue to be
normal GFNs associated with normal PFNs; when infact, these GFNs should
have been secure GFNs associated with device PFNs.
Move all the PFN associated with the SVM's GFNs to device PFNs, in
H_SVM_INIT_DONE. Skip the GFNs that are already Paged-in or Shared
through H_SVM_PAGE_IN.
Cc: Paul Mackerras <paulus@ozlabs.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Bharata B Rao <bharata@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Laurent Dufour <ldufour@linux.ibm.com>
Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Claudio Carvalho <cclaudio@linux.ibm.com>
Cc: kvm-ppc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
---
Documentation/powerpc/ultravisor.rst | 2 +
arch/powerpc/kvm/book3s_hv_uvmem.c | 219 ++++++++++++++++++++++++-----------
2 files changed, 154 insertions(+), 67 deletions(-)
diff --git a/Documentation/powerpc/ultravisor.rst b/Documentation/powerpc/ultravisor.rst
index 363736d..3bc8957 100644
--- a/Documentation/powerpc/ultravisor.rst
+++ b/Documentation/powerpc/ultravisor.rst
@@ -933,6 +933,8 @@ Return values
* H_UNSUPPORTED if called from the wrong context (e.g.
from an SVM or before an H_SVM_INIT_START
hypercall).
+ * H_STATE if the hypervisor could not successfully
+ transition the VM to Secure VM.
Description
~~~~~~~~~~~
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c
index 2ef1e03..36dda1d 100644
--- a/arch/powerpc/kvm/book3s_hv_uvmem.c
+++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
@@ -318,14 +318,149 @@ unsigned long kvmppc_h_svm_init_start(struct kvm *kvm)
return ret;
}
+static struct page *kvmppc_uvmem_get_page(unsigned long gpa, struct kvm *kvm);
+
+/*
+ * Alloc a PFN from private device memory pool. If @pagein is true,
+ * copy page from normal memory to secure memory using UV_PAGE_IN uvcall.
+ */
+static int kvmppc_svm_migrate_page(struct vm_area_struct *vma,
+ unsigned long start,
+ unsigned long end, unsigned long gpa, struct kvm *kvm,
+ unsigned long page_shift,
+ bool pagein)
+{
+ unsigned long src_pfn, dst_pfn = 0;
+ struct migrate_vma mig;
+ struct page *dpage;
+ struct page *spage;
+ unsigned long pfn;
+ int ret = 0;
+
+ memset(&mig, 0, sizeof(mig));
+ mig.vma = vma;
+ mig.start = start;
+ mig.end = end;
+ mig.src = &src_pfn;
+ mig.dst = &dst_pfn;
+
+ ret = migrate_vma_setup(&mig);
+ if (ret)
+ return ret;
+
+ if (!(*mig.src & MIGRATE_PFN_MIGRATE)) {
+ ret = -1;
+ goto out_finalize;
+ }
+
+ dpage = kvmppc_uvmem_get_page(gpa, kvm);
+ if (!dpage) {
+ ret = -1;
+ goto out_finalize;
+ }
+
+ if (pagein) {
+ pfn = *mig.src >> MIGRATE_PFN_SHIFT;
+ spage = migrate_pfn_to_page(*mig.src);
+ if (spage) {
+ ret = uv_page_in(kvm->arch.lpid, pfn << page_shift,
+ gpa, 0, page_shift);
+ if (ret)
+ goto out_finalize;
+ }
+ }
+
+ *mig.dst = migrate_pfn(page_to_pfn(dpage)) | MIGRATE_PFN_LOCKED;
+ migrate_vma_pages(&mig);
+out_finalize:
+ migrate_vma_finalize(&mig);
+ return ret;
+}
+
+static int uv_migrate_mem_slot(struct kvm *kvm,
+ const struct kvm_memory_slot *memslot)
+{
+ unsigned long gfn = memslot->base_gfn;
+ unsigned long end;
+ bool downgrade = false;
+ struct vm_area_struct *vma;
+ int i, ret = 0;
+ unsigned long start = gfn_to_hva(kvm, gfn);
+
+ if (kvm_is_error_hva(start))
+ return H_STATE;
+
+ end = start + (memslot->npages << PAGE_SHIFT);
+
+ down_write(&kvm->mm->mmap_sem);
+
+ mutex_lock(&kvm->arch.uvmem_lock);
+ vma = find_vma_intersection(kvm->mm, start, end);
+ if (!vma || vma->vm_start > start || vma->vm_end < end) {
+ ret = H_STATE;
+ goto out_unlock;
+ }
+
+ ret = ksm_madvise(vma, vma->vm_start, vma->vm_end,
+ MADV_UNMERGEABLE, &vma->vm_flags);
+ downgrade_write(&kvm->mm->mmap_sem);
+ downgrade = true;
+ if (ret) {
+ ret = H_STATE;
+ goto out_unlock;
+ }
+
+ for (i = 0; i < memslot->npages; i++, ++gfn) {
+ /* skip paged-in pages and shared pages */
+ if (kvmppc_gfn_is_uvmem_pfn(gfn, kvm, NULL) ||
+ kvmppc_gfn_is_uvmem_shared(gfn, kvm))
+ continue;
+
+ start = gfn_to_hva(kvm, gfn);
+ end = start + (1UL << PAGE_SHIFT);
+ ret = kvmppc_svm_migrate_page(vma, start, end,
+ (gfn << PAGE_SHIFT), kvm, PAGE_SHIFT, false);
+
+ if (ret)
+ goto out_unlock;
+ }
+
+out_unlock:
+ mutex_unlock(&kvm->arch.uvmem_lock);
+ if (downgrade)
+ up_read(&kvm->mm->mmap_sem);
+ else
+ up_write(&kvm->mm->mmap_sem);
+ return ret;
+}
+
unsigned long kvmppc_h_svm_init_done(struct kvm *kvm)
{
+ struct kvm_memslots *slots;
+ struct kvm_memory_slot *memslot;
+ int srcu_idx;
+ long ret = H_SUCCESS;
+
if (!(kvm->arch.secure_guest & KVMPPC_SECURE_INIT_START))
return H_UNSUPPORTED;
+ /* migrate any unmoved normal pfn to device pfns*/
+ srcu_idx = srcu_read_lock(&kvm->srcu);
+ slots = kvm_memslots(kvm);
+ kvm_for_each_memslot(memslot, slots) {
+ ret = uv_migrate_mem_slot(kvm, memslot);
+ if (ret) {
+ ret = H_STATE;
+ goto out;
+ }
+ }
+
kvm->arch.secure_guest |= KVMPPC_SECURE_INIT_DONE;
pr_info("LPID %d went secure\n", kvm->arch.lpid);
- return H_SUCCESS;
+
+out:
+ srcu_read_unlock(&kvm->srcu, srcu_idx);
+ return ret;
}
/*
@@ -459,68 +594,6 @@ static struct page *kvmppc_uvmem_get_page(unsigned long gpa, struct kvm *kvm)
}
/*
- * Alloc a PFN from private device memory pool and copy page from normal
- * memory to secure memory using UV_PAGE_IN uvcall.
- */
-static int kvmppc_svm_page_in(struct vm_area_struct *vma, unsigned long start,
- unsigned long end, unsigned long gpa, struct kvm *kvm,
- unsigned long page_shift, bool *downgrade)
-{
- unsigned long src_pfn, dst_pfn = 0;
- struct migrate_vma mig;
- struct page *spage;
- unsigned long pfn;
- struct page *dpage;
- int ret = 0;
-
- memset(&mig, 0, sizeof(mig));
- mig.vma = vma;
- mig.start = start;
- mig.end = end;
- mig.src = &src_pfn;
- mig.dst = &dst_pfn;
-
- /*
- * We come here with mmap_sem write lock held just for
- * ksm_madvise(), otherwise we only need read mmap_sem.
- * Hence downgrade to read lock once ksm_madvise() is done.
- */
- ret = ksm_madvise(vma, vma->vm_start, vma->vm_end,
- MADV_UNMERGEABLE, &vma->vm_flags);
- downgrade_write(&kvm->mm->mmap_sem);
- *downgrade = true;
- if (ret)
- return ret;
-
- ret = migrate_vma_setup(&mig);
- if (ret)
- return ret;
-
- if (!(*mig.src & MIGRATE_PFN_MIGRATE)) {
- ret = -1;
- goto out_finalize;
- }
-
- dpage = kvmppc_uvmem_get_page(gpa, kvm);
- if (!dpage) {
- ret = -1;
- goto out_finalize;
- }
-
- pfn = *mig.src >> MIGRATE_PFN_SHIFT;
- spage = migrate_pfn_to_page(*mig.src);
- if (spage)
- uv_page_in(kvm->arch.lpid, pfn << page_shift, gpa, 0,
- page_shift);
-
- *mig.dst = migrate_pfn(page_to_pfn(dpage)) | MIGRATE_PFN_LOCKED;
- migrate_vma_pages(&mig);
-out_finalize:
- migrate_vma_finalize(&mig);
- return ret;
-}
-
-/*
* Shares the page with HV, thus making it a normal page.
*
* - If the page is already secure, then provision a new page and share
@@ -623,11 +696,23 @@ unsigned long kvmppc_h_svm_page_in(struct kvm *kvm, unsigned long gpa,
if (!vma || vma->vm_start > start || vma->vm_end < end)
goto out_unlock;
- if (!kvmppc_svm_page_in(vma, start, end, gpa, kvm, page_shift,
- &downgrade)) {
- kvmppc_gfn_uvmem_shared(gfn, kvm, false);
- ret = H_SUCCESS;
+ ret = ksm_madvise(vma, vma->vm_start, vma->vm_end,
+ MADV_UNMERGEABLE, &vma->vm_flags);
+ downgrade_write(&kvm->mm->mmap_sem);
+ downgrade = true;
+ if (ret) {
+ ret = H_PARAMETER;
+ goto out_unlock;
}
+
+ ret = H_PARAMETER;
+ if (kvmppc_svm_migrate_page(vma, start, end, gpa, kvm, page_shift,
+ true))
+ goto out_unlock;
+
+ kvmppc_gfn_uvmem_shared(gfn, kvm, false);
+ ret = H_SUCCESS;
+
out_unlock:
mutex_unlock(&kvm->arch.uvmem_lock);
out:
--
1.8.3.1
^ permalink raw reply related
* [PATCH v1 2/4] KVM: PPC: Book3S HV: track shared GFNs of secure VMs
From: Ram Pai @ 2020-05-31 2:27 UTC (permalink / raw)
To: kvm-ppc, linuxppc-dev
Cc: ldufour, linuxram, cclaudio, bharata, aneesh.kumar, sukadev,
bauerman, david
In-Reply-To: <1590892071-25549-1-git-send-email-linuxram@us.ibm.com>
During the life of SVM, its GFNs can transition from secure to shared
state and vice-versa. Since the kernel does not track GFNs that are
shared, it is not possible to disambiguate a shared GFN from a GFN whose
PFN has not yet been migrated to a device-PFN.
The ability to identify a shared GFN is needed to skip migrating its PFN
to device PFN. This functionality is leveraged in a subsequent patch.
Add the ability to identify the state of a GFN.
Cc: Paul Mackerras <paulus@ozlabs.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Bharata B Rao <bharata@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Laurent Dufour <ldufour@linux.ibm.com>
Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Claudio Carvalho <cclaudio@linux.ibm.com>
Cc: kvm-ppc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
---
arch/powerpc/include/asm/kvm_book3s_uvmem.h | 6 +-
arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +-
arch/powerpc/kvm/book3s_hv.c | 2 +-
arch/powerpc/kvm/book3s_hv_uvmem.c | 115 ++++++++++++++++++++++++++--
4 files changed, 113 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_book3s_uvmem.h b/arch/powerpc/include/asm/kvm_book3s_uvmem.h
index 5a9834e..f0c5708 100644
--- a/arch/powerpc/include/asm/kvm_book3s_uvmem.h
+++ b/arch/powerpc/include/asm/kvm_book3s_uvmem.h
@@ -21,7 +21,8 @@ unsigned long kvmppc_h_svm_page_out(struct kvm *kvm,
int kvmppc_send_page_to_uv(struct kvm *kvm, unsigned long gfn);
unsigned long kvmppc_h_svm_init_abort(struct kvm *kvm);
void kvmppc_uvmem_drop_pages(const struct kvm_memory_slot *free,
- struct kvm *kvm, bool skip_page_out);
+ struct kvm *kvm, bool skip_page_out,
+ bool purge_gfn);
#else
static inline int kvmppc_uvmem_init(void)
{
@@ -75,6 +76,7 @@ static inline int kvmppc_send_page_to_uv(struct kvm *kvm, unsigned long gfn)
static inline void
kvmppc_uvmem_drop_pages(const struct kvm_memory_slot *free,
- struct kvm *kvm, bool skip_page_out) { }
+ struct kvm *kvm, bool skip_page_out,
+ bool purge_gfn) { }
#endif /* CONFIG_PPC_UV */
#endif /* __ASM_KVM_BOOK3S_UVMEM_H__ */
diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c
index 803940d..3448459 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_radix.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c
@@ -1100,7 +1100,7 @@ void kvmppc_radix_flush_memslot(struct kvm *kvm,
unsigned int shift;
if (kvm->arch.secure_guest & KVMPPC_SECURE_INIT_START)
- kvmppc_uvmem_drop_pages(memslot, kvm, true);
+ kvmppc_uvmem_drop_pages(memslot, kvm, true, false);
if (kvm->arch.secure_guest & KVMPPC_SECURE_INIT_DONE)
return;
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 103d13e..4c62bfe 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -5467,7 +5467,7 @@ static int kvmhv_svm_off(struct kvm *kvm)
continue;
kvm_for_each_memslot(memslot, slots) {
- kvmppc_uvmem_drop_pages(memslot, kvm, true);
+ kvmppc_uvmem_drop_pages(memslot, kvm, true, true);
uv_unregister_mem_slot(kvm->arch.lpid, memslot->id);
}
}
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c
index ea4a1f1..2ef1e03 100644
--- a/arch/powerpc/kvm/book3s_hv_uvmem.c
+++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
@@ -99,14 +99,56 @@
static DEFINE_SPINLOCK(kvmppc_uvmem_bitmap_lock);
#define KVMPPC_UVMEM_PFN (1UL << 63)
+#define KVMPPC_UVMEM_SHARED (1UL << 62)
+#define KVMPPC_UVMEM_FLAG_MASK (KVMPPC_UVMEM_PFN | KVMPPC_UVMEM_SHARED)
+#define KVMPPC_UVMEM_PFN_MASK (~KVMPPC_UVMEM_FLAG_MASK)
struct kvmppc_uvmem_slot {
struct list_head list;
unsigned long nr_pfns;
unsigned long base_pfn;
+ /*
+ * pfns array has an entry for each GFN of the memory slot.
+ *
+ * The GFN can be in one of the following states.
+ *
+ * (a) Secure - The GFN is secure. Only Ultravisor can access it.
+ * (b) Shared - The GFN is shared. Both Hypervisor and Ultravisor
+ * can access it.
+ * (c) Normal - The GFN is a normal. Only Hypervisor can access it.
+ *
+ * Secure GFN is associated with a devicePFN. Its pfn[] has
+ * KVMPPC_UVMEM_PFN flag set, and has the value of the device PFN
+ * KVMPPC_UVMEM_SHARED flag unset, and has the value of the device PFN
+ *
+ * Shared GFN is associated with a memoryPFN. Its pfn[] has
+ * KVMPPC_UVMEM_SHARED flag set. But its KVMPPC_UVMEM_PFN is not set,
+ * and there is no PFN value stored.
+ *
+ * Normal GFN is not associated with memoryPFN. Its pfn[] has
+ * KVMPPC_UVMEM_SHARED and KVMPPC_UVMEM_PFN flag unset, and no PFN
+ * value is stored.
+ *
+ * Any other combination of values in pfn[] leads to undefined
+ * behavior.
+ *
+ * Life cycle of a GFN --
+ *
+ * ---------------------------------------------------------
+ * | | Share | Unshare | SVM |slot |
+ * | | | | abort/ |flush |
+ * | | | | terminate | |
+ * ---------------------------------------------------------
+ * | | | | | |
+ * | Secure | Shared | Secure |Normal |Secure |
+ * | | | | | |
+ * | Shared | Shared | Secure |Normal |Shared |
+ * | | | | | |
+ * | Normal | Shared | Secure |Normal |Normal |
+ * ---------------------------------------------------------
+ */
unsigned long *pfns;
};
-
struct kvmppc_uvmem_page_pvt {
struct kvm *kvm;
unsigned long gpa;
@@ -175,7 +217,12 @@ static void kvmppc_uvmem_pfn_remove(unsigned long gfn, struct kvm *kvm)
list_for_each_entry(p, &kvm->arch.uvmem_pfns, list) {
if (gfn >= p->base_pfn && gfn < p->base_pfn + p->nr_pfns) {
- p->pfns[gfn - p->base_pfn] = 0;
+ /*
+ * Reset everything, but keep the KVMPPC_UVMEM_SHARED
+ * flag intact. A gfn continues to be shared or
+ * unshared, with or without an associated device pfn.
+ */
+ p->pfns[gfn - p->base_pfn] &= KVMPPC_UVMEM_SHARED;
return;
}
}
@@ -193,7 +240,7 @@ static bool kvmppc_gfn_is_uvmem_pfn(unsigned long gfn, struct kvm *kvm,
if (p->pfns[index] & KVMPPC_UVMEM_PFN) {
if (uvmem_pfn)
*uvmem_pfn = p->pfns[index] &
- ~KVMPPC_UVMEM_PFN;
+ KVMPPC_UVMEM_PFN_MASK;
return true;
} else
return false;
@@ -202,6 +249,38 @@ static bool kvmppc_gfn_is_uvmem_pfn(unsigned long gfn, struct kvm *kvm,
return false;
}
+static void kvmppc_gfn_uvmem_shared(unsigned long gfn, struct kvm *kvm,
+ bool set)
+{
+ struct kvmppc_uvmem_slot *p;
+
+ list_for_each_entry(p, &kvm->arch.uvmem_pfns, list) {
+ if (gfn >= p->base_pfn && gfn < p->base_pfn + p->nr_pfns) {
+ unsigned long index = gfn - p->base_pfn;
+
+ if (set)
+ p->pfns[index] |= KVMPPC_UVMEM_SHARED;
+ else
+ p->pfns[index] &= ~KVMPPC_UVMEM_SHARED;
+ return;
+ }
+ }
+}
+
+bool kvmppc_gfn_is_uvmem_shared(unsigned long gfn, struct kvm *kvm)
+{
+ struct kvmppc_uvmem_slot *p;
+
+ list_for_each_entry(p, &kvm->arch.uvmem_pfns, list) {
+ if (gfn >= p->base_pfn && gfn < p->base_pfn + p->nr_pfns) {
+ unsigned long index = gfn - p->base_pfn;
+
+ return (p->pfns[index] & KVMPPC_UVMEM_SHARED);
+ }
+ }
+ return false;
+}
+
unsigned long kvmppc_h_svm_init_start(struct kvm *kvm)
{
struct kvm_memslots *slots;
@@ -256,9 +335,13 @@ unsigned long kvmppc_h_svm_init_done(struct kvm *kvm)
* is HV side fault on these pages. Next we *get* these pages, forcing
* fault on them, do fault time migration to replace the device PTEs in
* QEMU page table with normal PTEs from newly allocated pages.
+ *
+ * if @purge_gfn is set, cleanup any information related to each of
+ * the GFNs associated with this memory slot.
*/
void kvmppc_uvmem_drop_pages(const struct kvm_memory_slot *free,
- struct kvm *kvm, bool skip_page_out)
+ struct kvm *kvm, bool skip_page_out,
+ bool purge_gfn)
{
int i;
struct kvmppc_uvmem_page_pvt *pvt;
@@ -269,11 +352,22 @@ void kvmppc_uvmem_drop_pages(const struct kvm_memory_slot *free,
struct page *uvmem_page;
mutex_lock(&kvm->arch.uvmem_lock);
+
+ if (purge_gfn) {
+ /*
+ * cleanup the shared status of the GFN here.
+ * Any device PFN associated with the GFN shall
+ * be cleaned up later, in kvmppc_uvmem_page_free()
+ * when the device PFN is actually disassociated
+ * from the GFN.
+ */
+ kvmppc_gfn_uvmem_shared(gfn, kvm, false);
+ }
+
if (!kvmppc_gfn_is_uvmem_pfn(gfn, kvm, &uvmem_pfn)) {
mutex_unlock(&kvm->arch.uvmem_lock);
continue;
}
-
uvmem_page = pfn_to_page(uvmem_pfn);
pvt = uvmem_page->zone_device_data;
pvt->skip_page_out = skip_page_out;
@@ -304,7 +398,7 @@ unsigned long kvmppc_h_svm_init_abort(struct kvm *kvm)
srcu_idx = srcu_read_lock(&kvm->srcu);
kvm_for_each_memslot(memslot, kvm_memslots(kvm))
- kvmppc_uvmem_drop_pages(memslot, kvm, false);
+ kvmppc_uvmem_drop_pages(memslot, kvm, false, true);
srcu_read_unlock(&kvm->srcu, srcu_idx);
@@ -470,8 +564,11 @@ static unsigned long kvmppc_share_page(struct kvm *kvm, unsigned long gpa,
goto retry;
}
- if (!uv_page_in(kvm->arch.lpid, pfn << page_shift, gpa, 0, page_shift))
+ if (!uv_page_in(kvm->arch.lpid, pfn << page_shift, gpa, 0,
+ page_shift)) {
+ kvmppc_gfn_uvmem_shared(gfn, kvm, true);
ret = H_SUCCESS;
+ }
kvm_release_pfn_clean(pfn);
mutex_unlock(&kvm->arch.uvmem_lock);
out:
@@ -527,8 +624,10 @@ unsigned long kvmppc_h_svm_page_in(struct kvm *kvm, unsigned long gpa,
goto out_unlock;
if (!kvmppc_svm_page_in(vma, start, end, gpa, kvm, page_shift,
- &downgrade))
+ &downgrade)) {
+ kvmppc_gfn_uvmem_shared(gfn, kvm, false);
ret = H_SUCCESS;
+ }
out_unlock:
mutex_unlock(&kvm->arch.uvmem_lock);
out:
--
1.8.3.1
^ permalink raw reply related
* [PATCH v1 1/4] KVM: PPC: Book3S HV: Fix function definition in book3s_hv_uvmem.c
From: Ram Pai @ 2020-05-31 2:27 UTC (permalink / raw)
To: kvm-ppc, linuxppc-dev
Cc: ldufour, linuxram, cclaudio, bharata, aneesh.kumar, sukadev,
bauerman, david
In-Reply-To: <1590892071-25549-1-git-send-email-linuxram@us.ibm.com>
Without this fix, GIT gets confused. It generates incorrect
function context for code changes. Weird, but true.
Cc: Paul Mackerras <paulus@ozlabs.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Bharata B Rao <bharata@linux.ibm.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Laurent Dufour <ldufour@linux.ibm.com>
Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Cc: David Gibson <david@gibson.dropbear.id.au>
Cc: Claudio Carvalho <cclaudio@linux.ibm.com>
Cc: kvm-ppc@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Ram Pai <linuxram@us.ibm.com>
---
arch/powerpc/kvm/book3s_hv_uvmem.c | 21 ++++++++++-----------
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c
index 79b1202..ea4a1f1 100644
--- a/arch/powerpc/kvm/book3s_hv_uvmem.c
+++ b/arch/powerpc/kvm/book3s_hv_uvmem.c
@@ -368,8 +368,7 @@ static struct page *kvmppc_uvmem_get_page(unsigned long gpa, struct kvm *kvm)
* Alloc a PFN from private device memory pool and copy page from normal
* memory to secure memory using UV_PAGE_IN uvcall.
*/
-static int
-kvmppc_svm_page_in(struct vm_area_struct *vma, unsigned long start,
+static int kvmppc_svm_page_in(struct vm_area_struct *vma, unsigned long start,
unsigned long end, unsigned long gpa, struct kvm *kvm,
unsigned long page_shift, bool *downgrade)
{
@@ -436,8 +435,8 @@ static struct page *kvmppc_uvmem_get_page(unsigned long gpa, struct kvm *kvm)
* 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)
+static unsigned long kvmppc_share_page(struct kvm *kvm, unsigned long gpa,
+ unsigned long page_shift)
{
int ret = H_PARAMETER;
@@ -486,9 +485,9 @@ static struct page *kvmppc_uvmem_get_page(unsigned long gpa, struct kvm *kvm)
* H_PAGE_IN_SHARED flag makes the page shared which means that the same
* memory in is visible from both UV and HV.
*/
-unsigned long
-kvmppc_h_svm_page_in(struct kvm *kvm, unsigned long gpa,
- unsigned long flags, unsigned long page_shift)
+unsigned long kvmppc_h_svm_page_in(struct kvm *kvm, unsigned long gpa,
+ unsigned long flags,
+ unsigned long page_shift)
{
bool downgrade = false;
unsigned long start, end;
@@ -545,10 +544,10 @@ static struct page *kvmppc_uvmem_get_page(unsigned long gpa, struct kvm *kvm)
* Provision a new page on HV side and copy over the contents
* from secure memory using UV_PAGE_OUT uvcall.
*/
-static int
-kvmppc_svm_page_out(struct vm_area_struct *vma, unsigned long start,
- unsigned long end, unsigned long page_shift,
- struct kvm *kvm, unsigned long gpa)
+static int kvmppc_svm_page_out(struct vm_area_struct *vma,
+ unsigned long start,
+ unsigned long end, unsigned long page_shift,
+ struct kvm *kvm, unsigned long gpa)
{
unsigned long src_pfn, dst_pfn = 0;
struct migrate_vma mig;
--
1.8.3.1
^ permalink raw reply related
* [PATCH v1 0/4] Migrate non-migrated pages of a SVM.
From: Ram Pai @ 2020-05-31 2:27 UTC (permalink / raw)
To: kvm-ppc, linuxppc-dev
Cc: ldufour, linuxram, cclaudio, bharata, aneesh.kumar, sukadev,
bauerman, david
This patch series migrates the non-migrate pages of a SVM.
This is required when the UV calls H_SVM_INIT_DONE, and
when a memory-slot is hotplugged to a Secure VM.
Laurent Dufour (1):
KVM: PPC: Book3S HV: migrate hot plugged memory
Ram Pai (3):
KVM: PPC: Book3S HV: Fix function definition in book3s_hv_uvmem.c
KVM: PPC: Book3S HV: track shared GFNs of secure VMs
KVM: PPC: Book3S HV: migrate remaining normal-GFNs to secure-GFNs in
H_SVM_INIT_DONE
Documentation/powerpc/ultravisor.rst | 2 +
arch/powerpc/include/asm/kvm_book3s_uvmem.h | 10 +-
arch/powerpc/kvm/book3s_64_mmu_radix.c | 2 +-
arch/powerpc/kvm/book3s_hv.c | 13 +-
arch/powerpc/kvm/book3s_hv_uvmem.c | 348 +++++++++++++++++++++-------
5 files changed, 284 insertions(+), 91 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: ppc64le and 32-bit LE userland compatibility
From: Will Springer @ 2020-05-31 0:57 UTC (permalink / raw)
To: Segher Boessenkool, linuxppc-dev
Cc: libc-alpha, eery, daniel, musl, binutils, libc-dev
In-Reply-To: <20200530192212.GG31009@gate.crashing.org>
On Saturday, May 30, 2020 12:22:12 PM PDT Segher Boessenkool wrote:
> The original sysv PowerPC supplement
> http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf
> supports LE as well, and most powerpcle ports use that. But, the
> big-endian Linux ABI differs in quite a few places, and it of course
> makes a lot better sense if powerpcle-linux follows that.
Right, I should have clarified I was talking about Linux ABIs
specifically.
> What patches did you need? I regularly build >30 cross compilers (on
> both BE and LE hosts; I haven't used 32-bit hosts for a long time, but
> in the past those worked fine as well). I also cross-built
> powerpcle-linux-gcc quite a few times (from powerpc64le, from powerpc64,
> from various x86).
There was just an assumption that LE == powerpc64le in libgo, spotted by
q66 (daniel@ on the CC). I just pushed the patch to [1].
> Almost no project that used 32-bit PowerPC in LE mode has sent patches
> to the upstreams.
Right, but I have heard concerns from at least one person familiar with
the ppc kernel about breaking existing users of this arch-endianness
combo, if any. It seems likely that none of those use upstream, though ^^;
> The ABI says long longs are passed in the same order in registers as it
> would be in memory; so the high part and the low part are swapped
> between BE and LE. Which registers make up a pair is exactly the same
> between the two. (You can verify this with an existing powerpcle-*
> compiler, too; I did, and we implement it correctly as far as I can
> see).
I'll give it a closer look. This is my first time poking at this sort of
thing in depth, so excuse my unfamiliarity!
> A huge factor in having good GCC support for powerpcle-linux (or
> anything else) is someone needs to regularly test it, and share test
> results with us (via gcc-testresults@). Hint hint hint :-)
>
> That way we know it is in good shape, know when we are regressing it,
> know there is interest in it.
Once I have more of a bootstrapped userland than a barely-functional
cross chroot, I'll get back to you on that :)
> gl;hf,
>
>
> Segher
Thanks,
Will [she/her]
[1]: https://github.com/Skirmisher/void-packages/blob/master/srcpkgs/gcc/patches/libgo-ppcle.patch
^ permalink raw reply
* Re: [musl] ppc64le and 32-bit LE userland compatibility
From: Will Springer @ 2020-05-30 22:56 UTC (permalink / raw)
To: Rich Felker, linuxppc-dev
Cc: libc-alpha, eery, daniel, musl, binutils, libc-dev
In-Reply-To: <20200529192426.GM1079@brightrain.aerifal.cx>
On Friday, May 29, 2020 12:24:27 PM PDT Rich Felker wrote:
> The argument passing for pread/pwrite is historically a mess and
> differs between archs. musl has a dedicated macro that archs can
> define to override it. But it looks like it should match regardless of
> BE vs LE, and musl already defines it for powerpc with the default
> definition, adding a zero arg to start on an even arg-slot index,
> which is an odd register (since ppc32 args start with an odd one, r3).
>
> > [6]:
> > https://gist.github.com/Skirmisher/02891c1a8cafa0ff18b2460933ef4f3c
> I don't think this is correct, but I'm confused about where it's
> getting messed up because it looks like it should already be right.
Hmm, interesting. Will have to go back to it I guess...
> > This was enough to fix up the `file` bug. I'm no seasoned kernel
> > hacker, though, and there is still concern over the right way to
> > approach this, whether it should live in the kernel or libc, etc.
> > Frankly, I don't know the ABI structure enough to understand why the
> > register padding has to be different in this case, or what
> > lower-level component is responsible for it.. For comparison, I had a
> > look at the mips tree, since it's bi-endian and has a similar 32/64
> > situation. There is a macro conditional upon endianness that is
> > responsible for munging long longs; it uses __MIPSEB__ and __MIPSEL__
> > instead of an if/else on the generic __LITTLE_ENDIAN__. Not sure what
> > to make of that. (It also simply swaps registers for LE, unlike what
> > I did for ppc.)
> Indeed the problem is probably that you need to swap registers for LE,
> not remove the padding slot. Did you check what happens if you pass a
> value larger than 32 bits?
>
> If so, the right way to fix this on the kernel side would be to
> construct the value as a union rather than by bitwise ops so it's
> endian-agnostic:
>
> (union { u32 parts[2]; u64 val; }){{ arg1, arg2 }}.val
>
> But the kernel folks might prefer endian ifdefs for some odd reason...
You are right, this does seem odd considering what the other archs do.
It's quite possible I made a silly mistake, of course...
I haven't tested with values outside the 32-bit range yet; again, this is
new territory for me, so I haven't exactly done exhaustive tests on
everything. I'll give it a closer look.
> > Also worth noting is the one other outstanding bug, where the
> > time-related syscalls in the 32-bit vDSO seem to return garbage. It
> > doesn't look like an endian bug to me, and it doesn't affect standard
> > syscalls (which is why if you run `date` on musl it prints the
> > correct time, unlike on glibc). The vDSO time functions are
> > implemented in ppc asm (arch/powerpc/kernel/vdso32/ gettimeofday.S),
> > and I've never touched the stuff, so if anyone has a clue I'm all
> > ears.
> Not sure about this. Worst-case, just leave it disabled until someone
> finds a fix.
Apparently these asm implementations are being replaced by the generic C
ones [1], so it may be this fixes itself on its own.
Thanks,
Will [she/her]
[1]: https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=173231
^ permalink raw reply
* Re: ppc64le and 32-bit LE userland compatibility
From: Will Springer @ 2020-05-30 22:17 UTC (permalink / raw)
To: linuxppc-dev, Christophe Leroy
Cc: libc-alpha, eery, daniel, musl, binutils, libc-dev
In-Reply-To: <8be94d2e-8e20-52b6-22e6-152b79a94139@csgroup.eu>
On Saturday, May 30, 2020 8:37:43 AM PDT Christophe Leroy wrote:
> There is a series at
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=173231 to
> switch powerpc to the Generic C VDSO.
>
> Can you try and see whether it fixes your issue ?
>
> Christophe
Sure thing, I spotted that after making the initial post. Will report back
with results.
Will [she/her]
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.7-6 tag
From: pr-tracker-bot @ 2020-05-30 19:35 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linux-kernel, linuxppc-dev, Linus Torvalds, ajd, dja
In-Reply-To: <87lfl9ikmp.fsf@mpe.ellerman.id.au>
The pull request you sent on Sun, 31 May 2020 00:05:02 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.7-6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ffeb595d84811dde16a28b33d8a7cf26d51d51b3
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: ppc64le and 32-bit LE userland compatibility
From: Segher Boessenkool @ 2020-05-30 19:22 UTC (permalink / raw)
To: Will Springer
Cc: libc-alpha, eery, daniel, musl, binutils, libc-dev, linuxppc-dev
In-Reply-To: <2047231.C4sosBPzcN@sheen>
Hi!
On Fri, May 29, 2020 at 07:03:48PM +0000, Will Springer wrote:
> Hey all, a couple of us over in #talos-workstation on freenode have been
> working on an effort to bring up a Linux PowerPC userland that runs in 32-bit
> little-endian mode, aka ppcle. As far as we can tell, no ABI has ever been
> designated for this
https://www.polyomino.org.uk/publications/2011/Power-Arch-32-bit-ABI-supp-1.0-Embedded.pdf
> (unless you count the patchset from a decade ago [1]), so
The original sysv PowerPC supplement
http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf
supports LE as well, and most powerpcle ports use that. But, the
big-endian Linux ABI differs in quite a few places, and it of course
makes a lot better sense if powerpcle-linux follows that.
> it's pretty much uncharted territory as far as Linux is concerned. We want to
> sync up with libc and the relevant kernel folks to establish the best path
> forward.
>
> The practical application that drove these early developments (as you might
> expect) is x86 emulation. The box86 project [2] implements a translation layer
> for ia32 library calls to native architecture ones; this way, emulation
> overhead is significantly reduced by relying on native libraries where
> possible (libc, libGL, etc.) instead of emulating an entire x86 userspace.
> box86 is primarily targeted at ARM, but it can be adapted to other
> architectures—so long as they match ia32's 32-bit, little-endian nature. Hence
> the need for a ppcle userland; modern POWER brought ppc64le as a supported
> configuration, but without a 32-bit equivalent there is no option for a 32/64
> multilib environment, as seen with ppc/ppc64 and arm/aarch64.
>
> Surprisingly, beyond minor patching of gcc to get crosscompile going,
What patches did you need? I regularly build >30 cross compilers (on
both BE and LE hosts; I haven't used 32-bit hosts for a long time, but
in the past those worked fine as well). I also cross-built
powerpcle-linux-gcc quite a few times (from powerpc64le, from powerpc64,
from various x86).
> bootstrapping the initial userland was not much of a problem. The work has
> been done on top of the Void Linux PowerPC project [3], and much of that is
> now present in its source package tree [4].
>
> The first issue with running the userland came from the ppc32 signal handler
> forcing BE in the MSR, causing any 32LE process receiving a signal (such as a
> shell receiving SIGCHLD) to terminate with SIGILL. This was trivially patched,
Heh :-)
> along with enabling the 32-bit vDSO on ppc64le kernels [5]. (Given that this
> behavior has been in place since 2006, I don't think anyone has been using the
> kernel in this state to run ppcle userlands.)
Almost no project that used 32-bit PowerPC in LE mode has sent patches
to the upstreams.
> The next problem concerns the ABI more directly. The failure mode was `file`
> surfacing EINVAL from pread64 when invoked on an ELF; pread64 was passed a
> garbage value for `pos`, which didn't appear to be caused by anything in
> `file`. Initially it seemed as though the 32-bit components of the arg were
> getting swapped, and we made hacky fixes to glibc and musl to put them in the
> "right order"; however, we weren't sure if that was the correct approach, or
> if there were knock-on effects we didn't know about. So we found the relevant
> compat code path in the kernel, at arch/powerpc/kernel/sys_ppc32.c, where
> there exists this comment:
>
> > /*
> > * long long munging:
> > * The 32 bit ABI passes long longs in an odd even register pair.
> > */
>
> It seems that the opposite is true in LE mode, and something is expecting long
> longs to start on an even register. I realized this after I tried swapping hi/
> lo `u32`s here and didn't see an improvement. I whipped up a patch [6] that
> switches which syscalls use padding arguments depending on endianness, while
> hopefully remaining tidy enough to be unobtrusive. (I took some liberties with
> variable names/types so that the macro could be consistent.)
The ABI says long longs are passed in the same order in registers as it
would be in memory; so the high part and the low part are swapped between
BE and LE. Which registers make up a pair is exactly the same between
the two. (You can verify this with an existing powerpcle-* compiler, too;
I did, and we implement it correctly as far as I can see).
> This was enough to fix up the `file` bug. I'm no seasoned kernel hacker,
> though, and there is still concern over the right way to approach this,
> whether it should live in the kernel or libc, etc. Frankly, I don't know the
> ABI structure enough to understand why the register padding has to be
> different in this case, or what lower-level component is responsible for it.
> For comparison, I had a look at the mips tree, since it's bi-endian and has a
> similar 32/64 situation. There is a macro conditional upon endianness that is
> responsible for munging long longs; it uses __MIPSEB__ and __MIPSEL__ instead
> of an if/else on the generic __LITTLE_ENDIAN__. Not sure what to make of that.
> (It also simply swaps registers for LE, unlike what I did for ppc.)
But you should :-)
> Also worth noting is the one other outstanding bug, where the time-related
> syscalls in the 32-bit vDSO seem to return garbage. It doesn't look like an
> endian bug to me, and it doesn't affect standard syscalls (which is why if you
> run `date` on musl it prints the correct time, unlike on glibc). The vDSO time
> functions are implemented in ppc asm (arch/powerpc/kernel/vdso32/
> gettimeofday.S), and I've never touched the stuff, so if anyone has a clue I'm
> all ears.
>
> Again, I'd appreciate feedback on the approach to take here, in order to
> touch/special-case only the minimum necessary, while keeping the kernel/libc
> folks happy.
A huge factor in having good GCC support for powerpcle-linux (or anything
else) is someone needs to regularly test it, and share test results with
us (via gcc-testresults@). Hint hint hint :-)
That way we know it is in good shape, know when we are regressing it,
know there is interest in it.
gl;hf,
Segher
^ permalink raw reply
* Re: [PATCH] powerpc/32: disable KASAN with pages bigger than 16k
From: Christophe Leroy @ 2020-05-30 17:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <7195fcde7314ccbf7a081b356084a69d421b10d4.1590660977.git.christophe.leroy@csgroup.eu>
Le 28/05/2020 à 12:17, Christophe Leroy a écrit :
> Mapping of early shadow area is implemented by using a single static
> page table having all entries pointing to the same early shadow page.
> The shadow area must therefore occupy full PGD entries.
>
> The shadow area has a size of 128Mbytes starting at 0xf8000000.
> With 4k pages, a PGD entry is 4Mbytes
> With 16k pages, a PGD entry is 64Mbytes
> With 64k pages, a PGD entry is 256Mbytes which is too big.
That's for 32k pages that a PGD is 256Mbytes.
With 64k pages, a PGD entry is 1Gbytes which is too big.
Michael, can you fix the commit log ?
Thanks
Christophe
>
> Until we rework the early shadow mapping, disable KASAN when the
> page size is too big.
>
> Reported-by: kbuild test robot <lkp@intel.com>
> Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/Kconfig | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 1dfa59126fcf..066b36bf9efa 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -169,8 +169,8 @@ config PPC
> select HAVE_ARCH_AUDITSYSCALL
> select HAVE_ARCH_HUGE_VMAP if PPC_BOOK3S_64 && PPC_RADIX_MMU
> select HAVE_ARCH_JUMP_LABEL
> - select HAVE_ARCH_KASAN if PPC32
> - select HAVE_ARCH_KASAN_VMALLOC if PPC32
> + select HAVE_ARCH_KASAN if PPC32 && PPC_PAGE_SHIFT <= 14
> + select HAVE_ARCH_KASAN_VMALLOC if PPC32 && PPC_PAGE_SHIFT <= 14
> select HAVE_ARCH_KGDB
> select HAVE_ARCH_MMAP_RND_BITS
> select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
>
^ permalink raw reply
* [PATCH v2] powerpc/32s: Fix another build failure with CONFIG_PPC_KUAP_DEBUG
From: Christophe Leroy @ 2020-05-30 17:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
'thread' doesn't exist in kuap_check() macro.
Use 'current' instead.
Reported-by: kbuild test robot <lkp@intel.com>
Fixes: a68c31fc01ef ("powerpc/32s: Implement Kernel Userspace Access Protection")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
v2: Changed author and signed-off-by ... and added asm/bug.h
There are days when you'd better go sleeping instead of wanting to send the fix.
And there are days you stare at your code, think it is good, prepare the patch,
test it, find another bug, fix it, test it ... and send the first patch you prepared :(
hence this second fix for the same bug.
---
arch/powerpc/include/asm/book3s/32/kup.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/book3s/32/kup.h b/arch/powerpc/include/asm/book3s/32/kup.h
index db0a1c281587..a41cfc7cc669 100644
--- a/arch/powerpc/include/asm/book3s/32/kup.h
+++ b/arch/powerpc/include/asm/book3s/32/kup.h
@@ -2,6 +2,7 @@
#ifndef _ASM_POWERPC_BOOK3S_32_KUP_H
#define _ASM_POWERPC_BOOK3S_32_KUP_H
+#include <asm/bug.h>
#include <asm/book3s/32/mmu-hash.h>
#ifdef __ASSEMBLY__
@@ -75,7 +76,7 @@
.macro kuap_check current, gpr
#ifdef CONFIG_PPC_KUAP_DEBUG
- lwz \gpr, KUAP(thread)
+ lwz \gpr, THREAD + KUAP(\current)
999: twnei \gpr, 0
EMIT_BUG_ENTRY 999b, __FILE__, __LINE__, (BUGFLAG_WARNING | BUGFLAG_ONCE)
#endif
--
2.25.0
^ permalink raw reply related
* Re: [RFC PATCH 1/2] libnvdimm: Add prctl control for disabling synchronous fault support.
From: Dan Williams @ 2020-05-30 16:35 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Jan Kara, linux-nvdimm, jack, Jeff Moyer, Oliver O'Halloran,
Michal Suchánek, linuxppc-dev
In-Reply-To: <7f163562-e7e3-7668-7415-c40e57c32582@linux.ibm.com>
On Sat, May 30, 2020 at 12:18 AM Aneesh Kumar K.V
<aneesh.kumar@linux.ibm.com> wrote:
>
> On 5/30/20 12:52 AM, Dan Williams wrote:
> > On Fri, May 29, 2020 at 3:55 AM Aneesh Kumar K.V
> > <aneesh.kumar@linux.ibm.com> wrote:
> >>
> >> On 5/29/20 3:22 PM, Jan Kara wrote:
> >>> Hi!
> >>>
> >>> On Fri 29-05-20 15:07:31, Aneesh Kumar K.V wrote:
> >>>> Thanks Michal. I also missed Jeff in this email thread.
> >>>
> >>> And I think you'll also need some of the sched maintainers for the prctl
> >>> bits...
> >>>
> >>>> On 5/29/20 3:03 PM, Michal Suchánek wrote:
> >>>>> Adding Jan
> >>>>>
> >>>>> On Fri, May 29, 2020 at 11:11:39AM +0530, Aneesh Kumar K.V wrote:
> >>>>>> With POWER10, architecture is adding new pmem flush and sync instructions.
> >>>>>> The kernel should prevent the usage of MAP_SYNC if applications are not using
> >>>>>> the new instructions on newer hardware.
> >>>>>>
> >>>>>> This patch adds a prctl option MAP_SYNC_ENABLE that can be used to enable
> >>>>>> the usage of MAP_SYNC. The kernel config option is added to allow the user
> >>>>>> to control whether MAP_SYNC should be enabled by default or not.
> >>>>>>
> >>>>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> >>> ...
> >>>>>> diff --git a/kernel/fork.c b/kernel/fork.c
> >>>>>> index 8c700f881d92..d5a9a363e81e 100644
> >>>>>> --- a/kernel/fork.c
> >>>>>> +++ b/kernel/fork.c
> >>>>>> @@ -963,6 +963,12 @@ __cacheline_aligned_in_smp DEFINE_SPINLOCK(mmlist_lock);
> >>>>>> static unsigned long default_dump_filter = MMF_DUMP_FILTER_DEFAULT;
> >>>>>> +#ifdef CONFIG_ARCH_MAP_SYNC_DISABLE
> >>>>>> +unsigned long default_map_sync_mask = MMF_DISABLE_MAP_SYNC_MASK;
> >>>>>> +#else
> >>>>>> +unsigned long default_map_sync_mask = 0;
> >>>>>> +#endif
> >>>>>> +
> >>>
> >>> I'm not sure CONFIG is really the right approach here. For a distro that would
> >>> basically mean to disable MAP_SYNC for all PPC kernels unless application
> >>> explicitly uses the right prctl. Shouldn't we rather initialize
> >>> default_map_sync_mask on boot based on whether the CPU we run on requires
> >>> new flush instructions or not? Otherwise the patch looks sensible.
> >>>
> >>
> >> yes that is correct. We ideally want to deny MAP_SYNC only w.r.t
> >> POWER10. But on a virtualized platform there is no easy way to detect
> >> that. We could ideally hook this into the nvdimm driver where we look at
> >> the new compat string ibm,persistent-memory-v2 and then disable MAP_SYNC
> >> if we find a device with the specific value.
> >>
> >> BTW with the recent changes I posted for the nvdimm driver, older kernel
> >> won't initialize persistent memory device on newer hardware. Newer
> >> hardware will present the device to OS with a different device tree
> >> compat string.
> >>
> >> My expectation w.r.t this patch was, Distro would want to mark
> >> CONFIG_ARCH_MAP_SYNC_DISABLE=n based on the different application
> >> certification. Otherwise application will have to end up calling the
> >> prctl(MMF_DISABLE_MAP_SYNC, 0) any way. If that is the case, should this
> >> be dependent on P10?
> >>
> >> With that I am wondering should we even have this patch? Can we expect
> >> userspace get updated to use new instruction?.
> >>
> >> With ppc64 we never had a real persistent memory device available for
> >> end user to try. The available persistent memory stack was using vPMEM
> >> which was presented as a volatile memory region for which there is no
> >> need to use any of the flush instructions. We could safely assume that
> >> as we get applications certified/verified for working with pmem device
> >> on ppc64, they would all be using the new instructions?
> >
> > I think prctl is the wrong interface for this. I was thinking a sysfs
> > interface along the same lines as /sys/block/pmemX/dax/write_cache.
> > That attribute is toggling DAXDEV_WRITE_CACHE for the determination of
> > whether the platform or the kernel needs to handle cache flushing
> > relative to power loss. A similar attribute can be established for
> > DAXDEV_SYNC, it would simply default to off based on a configuration
> > time policy, but be dynamically changeable at runtime via sysfs.
> >
> > These flags are device properties that affect the kernel and
> > userspace's handling of persistence.
> >
>
> That will not handle the scenario with multiple applications using the
> same fsdax mount point where one is updated to use the new instruction
> and the other is not.
Right, it needs to be a global setting / flag day to switch from one
regime to another. Per-process control is a recipe for disaster.
^ permalink raw reply
* Re: ppc64le and 32-bit LE userland compatibility
From: Christophe Leroy @ 2020-05-30 15:37 UTC (permalink / raw)
To: Will Springer, linuxppc-dev
Cc: libc-alpha, eery, daniel, musl, binutils, libc-dev
In-Reply-To: <2047231.C4sosBPzcN@sheen>
Le 29/05/2020 à 21:03, Will Springer a écrit :
[...]
>
> Also worth noting is the one other outstanding bug, where the time-related
> syscalls in the 32-bit vDSO seem to return garbage. It doesn't look like an
> endian bug to me, and it doesn't affect standard syscalls (which is why if you
> run `date` on musl it prints the correct time, unlike on glibc). The vDSO time
> functions are implemented in ppc asm (arch/powerpc/kernel/vdso32/
> gettimeofday.S), and I've never touched the stuff, so if anyone has a clue I'm
> all ears.
>
There is a series at
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=173231 to
switch powerpc to the Generic C VDSO.
Can you try and see whether it fixes your issue ?
Christophe
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.7-6 tag
From: Michael Ellerman @ 2020-05-30 14:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linuxppc-dev, ajd, dja
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Linus,
Please pull two more powerpc fixes for 5.7. These are both regressions with
small "obviously correct" fixes.
cheers
The following changes since commit 8659a0e0efdd975c73355dbc033f79ba3b31e82c:
powerpc/64s: Disable STRICT_KERNEL_RWX (2020-05-22 00:04:51 +1000)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.7-6
for you to fetch changes up to 2f26ed1764b42a8c40d9c48441c73a70d805decf:
powerpc/64s: Disable sanitisers for C syscall/interrupt entry/exit code (2020-05-29 21:12:09 +1000)
- ------------------------------------------------------------------
powerpc fixes for 5.7 #6
A fix for the recent change to how we restore non-volatile GPRs, which broke our
emulation of reading from the DSCR (Data Stream Control Register).
And a fix for the recent rewrite of interrupt/syscall exit in C, we need to
exclude KCOV from that code, otherwise it can lead to unrecoverable faults.
Thanks to:
Daniel Axtens.
- ------------------------------------------------------------------
Daniel Axtens (1):
powerpc/64s: Disable sanitisers for C syscall/interrupt entry/exit code
Michael Ellerman (1):
powerpc/64s: Fix restore of NV GPRs after facility unavailable exception
arch/powerpc/kernel/Makefile | 3 +++
arch/powerpc/kernel/exceptions-64s.S | 2 ++
2 files changed, 5 insertions(+)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl7SZ9oACgkQUevqPMjh
pYCF0g//cJYxcH020cVm2jZL5Smcfqr3mYRcGnY/IsEJ28y7HFc30HnoxiBtwO2Z
BwZqqW80IQpDieHS9GZ//IbGaHrrrj5HeyGfA5F6IsKrZXsb9EG++njaKqGZljX5
NStMVMJ+zFs8b+ZVPtA5yQVy4EQO5QlB3A19BIsI7VnqNI/h6R9wXHaAguVz2DUL
AydK/cdU0LdOXnPewY3S3P4HVaUkBE/UrqpekBePJ89obOvUVsbP1C+syDYQLgzA
y43zFPZurVb5UOpEXs9hKoqLnciM5LBKCbk6JV001Hvalb8Bobo/4vvrmxC/BSUs
B0kI6ZHvojTj/cQ7c26B0uEab6AZYdP7TzAIjpP2xoLHvLaWlbGlrOzSz5xNp5B5
lkT8WZCcU8/kQx2hsjOcOOQV6JIMkTDeB7lTm3iwcVQihJDemNu0XxZIAi8gbOzr
46BXNFKVv9ItjzxSIbUtcxl5mpiwnV0XoDw4IM7xDdKnpLG8z9yzrYuBPyQ2gEDB
KhnvTJQry9B4I98EoKoXvMGMttL9BmrYWJ/7P89hTWZT4fs6dOox9Pf+UOHBp3Tk
I/qxG9zzWlf5zXJKUKyTqLv4SIbQNCx7IAqkPkaR9AGCoLCNyapNfZ5orfh6TFHc
n4J9suaFG9TFF7frIMGZNcIt8MBjPlXcJhQQ+s2KCOD4NZE+534=
=KF+h
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [RFC PATCH 1/2] libnvdimm: Add prctl control for disabling synchronous fault support.
From: Aneesh Kumar K.V @ 2020-05-30 7:18 UTC (permalink / raw)
To: Dan Williams
Cc: Jan Kara, linux-nvdimm, jack, Jeff Moyer, Oliver O'Halloran,
Michal Suchánek, linuxppc-dev
In-Reply-To: <CAPcyv4jrss3dFcCOar3JTFnuN0_pgFNtBPiJzUdKxtiax6pPgQ@mail.gmail.com>
On 5/30/20 12:52 AM, Dan Williams wrote:
> On Fri, May 29, 2020 at 3:55 AM Aneesh Kumar K.V
> <aneesh.kumar@linux.ibm.com> wrote:
>>
>> On 5/29/20 3:22 PM, Jan Kara wrote:
>>> Hi!
>>>
>>> On Fri 29-05-20 15:07:31, Aneesh Kumar K.V wrote:
>>>> Thanks Michal. I also missed Jeff in this email thread.
>>>
>>> And I think you'll also need some of the sched maintainers for the prctl
>>> bits...
>>>
>>>> On 5/29/20 3:03 PM, Michal Suchánek wrote:
>>>>> Adding Jan
>>>>>
>>>>> On Fri, May 29, 2020 at 11:11:39AM +0530, Aneesh Kumar K.V wrote:
>>>>>> With POWER10, architecture is adding new pmem flush and sync instructions.
>>>>>> The kernel should prevent the usage of MAP_SYNC if applications are not using
>>>>>> the new instructions on newer hardware.
>>>>>>
>>>>>> This patch adds a prctl option MAP_SYNC_ENABLE that can be used to enable
>>>>>> the usage of MAP_SYNC. The kernel config option is added to allow the user
>>>>>> to control whether MAP_SYNC should be enabled by default or not.
>>>>>>
>>>>>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>>> ...
>>>>>> diff --git a/kernel/fork.c b/kernel/fork.c
>>>>>> index 8c700f881d92..d5a9a363e81e 100644
>>>>>> --- a/kernel/fork.c
>>>>>> +++ b/kernel/fork.c
>>>>>> @@ -963,6 +963,12 @@ __cacheline_aligned_in_smp DEFINE_SPINLOCK(mmlist_lock);
>>>>>> static unsigned long default_dump_filter = MMF_DUMP_FILTER_DEFAULT;
>>>>>> +#ifdef CONFIG_ARCH_MAP_SYNC_DISABLE
>>>>>> +unsigned long default_map_sync_mask = MMF_DISABLE_MAP_SYNC_MASK;
>>>>>> +#else
>>>>>> +unsigned long default_map_sync_mask = 0;
>>>>>> +#endif
>>>>>> +
>>>
>>> I'm not sure CONFIG is really the right approach here. For a distro that would
>>> basically mean to disable MAP_SYNC for all PPC kernels unless application
>>> explicitly uses the right prctl. Shouldn't we rather initialize
>>> default_map_sync_mask on boot based on whether the CPU we run on requires
>>> new flush instructions or not? Otherwise the patch looks sensible.
>>>
>>
>> yes that is correct. We ideally want to deny MAP_SYNC only w.r.t
>> POWER10. But on a virtualized platform there is no easy way to detect
>> that. We could ideally hook this into the nvdimm driver where we look at
>> the new compat string ibm,persistent-memory-v2 and then disable MAP_SYNC
>> if we find a device with the specific value.
>>
>> BTW with the recent changes I posted for the nvdimm driver, older kernel
>> won't initialize persistent memory device on newer hardware. Newer
>> hardware will present the device to OS with a different device tree
>> compat string.
>>
>> My expectation w.r.t this patch was, Distro would want to mark
>> CONFIG_ARCH_MAP_SYNC_DISABLE=n based on the different application
>> certification. Otherwise application will have to end up calling the
>> prctl(MMF_DISABLE_MAP_SYNC, 0) any way. If that is the case, should this
>> be dependent on P10?
>>
>> With that I am wondering should we even have this patch? Can we expect
>> userspace get updated to use new instruction?.
>>
>> With ppc64 we never had a real persistent memory device available for
>> end user to try. The available persistent memory stack was using vPMEM
>> which was presented as a volatile memory region for which there is no
>> need to use any of the flush instructions. We could safely assume that
>> as we get applications certified/verified for working with pmem device
>> on ppc64, they would all be using the new instructions?
>
> I think prctl is the wrong interface for this. I was thinking a sysfs
> interface along the same lines as /sys/block/pmemX/dax/write_cache.
> That attribute is toggling DAXDEV_WRITE_CACHE for the determination of
> whether the platform or the kernel needs to handle cache flushing
> relative to power loss. A similar attribute can be established for
> DAXDEV_SYNC, it would simply default to off based on a configuration
> time policy, but be dynamically changeable at runtime via sysfs.
>
> These flags are device properties that affect the kernel and
> userspace's handling of persistence.
>
That will not handle the scenario with multiple applications using the
same fsdax mount point where one is updated to use the new instruction
and the other is not.
-aneeseh
^ permalink raw reply
* Re: [PATCH v3 5/7] powerpc/pmem/of_pmem: Update of_pmem to use the new barrier instruction.
From: kbuild test robot @ 2020-05-30 3:08 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev, mpe, linux-nvdimm
Cc: kbuild-all, Aneesh Kumar K.V, clang-built-linux, oohall, alistair,
dan.j.williams
In-Reply-To: <20200519055502.128318-5-aneesh.kumar@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 13484 bytes --]
Hi "Aneesh,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.7-rc7]
[cannot apply to next-20200529]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Aneesh-Kumar-K-V/powerpc-pmem-Restrict-papr_scm-to-P8-and-above/20200519-195350
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-randconfig-r016-20200529 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 2d068e534f1671459e1b135852c1b3c10502e929)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>, old ones prefixed by <<):
In file included from arch/powerpc/kernel/syscall_64.c:4:
In file included from arch/powerpc/include/asm/asm-prototypes.h:12:
>> arch/powerpc/include/asm/cacheflush.h:126:6: error: implicit declaration of function 'cpu_has_feature' [-Werror,-Wimplicit-function-declaration]
if (cpu_has_feature(CPU_FTR_ARCH_207S))
^
arch/powerpc/include/asm/cacheflush.h:126:6: note: did you mean 'mmu_has_feature'?
arch/powerpc/include/asm/mmu.h:234:20: note: 'mmu_has_feature' declared here
static inline bool mmu_has_feature(unsigned long feature)
^
In file included from arch/powerpc/kernel/syscall_64.c:4:
In file included from arch/powerpc/include/asm/asm-prototypes.h:17:
In file included from arch/powerpc/include/asm/mmu_context.h:12:
In file included from arch/powerpc/include/asm/cputhreads.h:7:
>> arch/powerpc/include/asm/cpu_has_feature.h:49:20: error: static declaration of 'cpu_has_feature' follows non-static declaration
static inline bool cpu_has_feature(unsigned long feature)
^
arch/powerpc/include/asm/cacheflush.h:126:6: note: previous implicit declaration is here
if (cpu_has_feature(CPU_FTR_ARCH_207S))
^
2 errors generated.
--
In file included from arch/powerpc/kernel/kprobes.c:23:
>> arch/powerpc/include/asm/cacheflush.h:126:6: error: implicit declaration of function 'cpu_has_feature' [-Werror,-Wimplicit-function-declaration]
if (cpu_has_feature(CPU_FTR_ARCH_207S))
^
arch/powerpc/include/asm/cacheflush.h:126:6: note: did you mean 'mmu_has_feature'?
arch/powerpc/include/asm/mmu.h:234:20: note: 'mmu_has_feature' declared here
static inline bool mmu_has_feature(unsigned long feature)
^
1 error generated.
--
In file included from arch/powerpc/kernel/optprobes.c:15:
>> arch/powerpc/include/asm/cacheflush.h:126:6: error: implicit declaration of function 'cpu_has_feature' [-Werror,-Wimplicit-function-declaration]
if (cpu_has_feature(CPU_FTR_ARCH_207S))
^
arch/powerpc/include/asm/cacheflush.h:126:6: note: did you mean 'mmu_has_feature'?
arch/powerpc/include/asm/mmu.h:234:20: note: 'mmu_has_feature' declared here
static inline bool mmu_has_feature(unsigned long feature)
^
arch/powerpc/kernel/optprobes.c:149:6: warning: no previous prototype for function 'patch_imm32_load_insns' [-Wmissing-prototypes]
void patch_imm32_load_insns(unsigned int val, kprobe_opcode_t *addr)
^
arch/powerpc/kernel/optprobes.c:149:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
void patch_imm32_load_insns(unsigned int val, kprobe_opcode_t *addr)
^
static
arch/powerpc/kernel/optprobes.c:167:6: warning: no previous prototype for function 'patch_imm64_load_insns' [-Wmissing-prototypes]
void patch_imm64_load_insns(unsigned long val, int reg, kprobe_opcode_t *addr)
^
arch/powerpc/kernel/optprobes.c:167:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
void patch_imm64_load_insns(unsigned long val, int reg, kprobe_opcode_t *addr)
^
static
2 warnings and 1 error generated.
--
In file included from arch/powerpc/kernel/epapr_paravirt.c:11:
>> arch/powerpc/include/asm/cacheflush.h:126:6: error: implicit declaration of function 'cpu_has_feature' [-Werror,-Wimplicit-function-declaration]
if (cpu_has_feature(CPU_FTR_ARCH_207S))
^
arch/powerpc/include/asm/cacheflush.h:126:6: note: did you mean 'mmu_has_feature'?
arch/powerpc/include/asm/mmu.h:234:20: note: 'mmu_has_feature' declared here
static inline bool mmu_has_feature(unsigned long feature)
^
In file included from arch/powerpc/kernel/epapr_paravirt.c:13:
In file included from arch/powerpc/include/asm/machdep.h:8:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/powerpc/include/asm/io.h:33:
In file included from arch/powerpc/include/asm/delay.h:7:
In file included from arch/powerpc/include/asm/time.h:17:
>> arch/powerpc/include/asm/cpu_has_feature.h:49:20: error: static declaration of 'cpu_has_feature' follows non-static declaration
static inline bool cpu_has_feature(unsigned long feature)
^
arch/powerpc/include/asm/cacheflush.h:126:6: note: previous implicit declaration is here
if (cpu_has_feature(CPU_FTR_ARCH_207S))
^
In file included from arch/powerpc/kernel/epapr_paravirt.c:13:
In file included from arch/powerpc/include/asm/machdep.h:8:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/powerpc/include/asm/io.h:605:
arch/powerpc/include/asm/io-defs.h:23:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
DEF_PCI_AC_RET(inb, u8, (unsigned long port), (port), pio, port)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:593:9: note: expanded from macro 'DEF_PCI_AC_RET'
return __do_##name al; ^~~~~~~~~~~~~~
<scratch space>:32:1: note: expanded from here
__do_inb
^
arch/powerpc/include/asm/io.h:524:53: note: expanded from macro '__do_inb'
#define __do_inb(port) readb((PCI_IO_ADDR)_IO_BASE + port);
~~~~~~~~~~~~~~~~~~~~~ ^
In file included from arch/powerpc/kernel/epapr_paravirt.c:13:
In file included from arch/powerpc/include/asm/machdep.h:8:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/powerpc/include/asm/io.h:605:
arch/powerpc/include/asm/io-defs.h:24:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
DEF_PCI_AC_RET(inw, u16, (unsigned long port), (port), pio, port)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:593:9: note: expanded from macro 'DEF_PCI_AC_RET'
return __do_##name al; ^~~~~~~~~~~~~~
<scratch space>:34:1: note: expanded from here
__do_inw
^
arch/powerpc/include/asm/io.h:525:53: note: expanded from macro '__do_inw'
#define __do_inw(port) readw((PCI_IO_ADDR)_IO_BASE + port);
~~~~~~~~~~~~~~~~~~~~~ ^
In file included from arch/powerpc/kernel/epapr_paravirt.c:13:
In file included from arch/powerpc/include/asm/machdep.h:8:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/powerpc/include/asm/io.h:605:
arch/powerpc/include/asm/io-defs.h:25:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
DEF_PCI_AC_RET(inl, u32, (unsigned long port), (port), pio, port)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:593:9: note: expanded from macro 'DEF_PCI_AC_RET'
return __do_##name al; ^~~~~~~~~~~~~~
<scratch space>:36:1: note: expanded from here
__do_inl
^
arch/powerpc/include/asm/io.h:526:53: note: expanded from macro '__do_inl'
#define __do_inl(port) readl((PCI_IO_ADDR)_IO_BASE + port);
~~~~~~~~~~~~~~~~~~~~~ ^
In file included from arch/powerpc/kernel/epapr_paravirt.c:13:
In file included from arch/powerpc/include/asm/machdep.h:8:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/powerpc/include/asm/io.h:605:
arch/powerpc/include/asm/io-defs.h:26:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(outb, (u8 val, unsigned long port), (val, port), pio, port)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:602:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; ^~~~~~~~~~~~~~
<scratch space>:38:1: note: expanded from here
__do_outb
^
arch/powerpc/include/asm/io.h:521:62: note: expanded from macro '__do_outb'
#define __do_outb(val, port) writeb(val,(PCI_IO_ADDR)_IO_BASE+port);
~~~~~~~~~~~~~~~~~~~~~^
In file included from arch/powerpc/kernel/epapr_paravirt.c:13:
In file included from arch/powerpc/include/asm/machdep.h:8:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/powerpc/include/asm/io.h:605:
arch/powerpc/include/asm/io-defs.h:27:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(outw, (u16 val, unsigned long port), (val, port), pio, port)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:602:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; ^~~~~~~~~~~~~~
<scratch space>:40:1: note: expanded from here
__do_outw
^
arch/powerpc/include/asm/io.h:522:62: note: expanded from macro '__do_outw'
#define __do_outw(val, port) writew(val,(PCI_IO_ADDR)_IO_BASE+port);
~~~~~~~~~~~~~~~~~~~~~^
In file included from arch/powerpc/kernel/epapr_paravirt.c:13:
In file included from arch/powerpc/include/asm/machdep.h:8:
In file included from include/linux/dma-mapping.h:11:
In file included from include/linux/scatterlist.h:9:
In file included from arch/powerpc/include/asm/io.h:605:
arch/powerpc/include/asm/io-defs.h:28:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic]
DEF_PCI_AC_NORET(outl, (u32 val, unsigned long port), (val, port), pio, port)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
arch/powerpc/include/asm/io.h:602:3: note: expanded from macro 'DEF_PCI_AC_NORET'
__do_##name al; --
In file included from arch/powerpc/lib/pmem.c:10:
>> arch/powerpc/include/asm/cacheflush.h:126:6: error: implicit declaration of function 'cpu_has_feature' [-Werror,-Wimplicit-function-declaration]
if (cpu_has_feature(CPU_FTR_ARCH_207S))
^
arch/powerpc/include/asm/cacheflush.h:126:6: note: did you mean 'mmu_has_feature'?
arch/powerpc/include/asm/mmu.h:234:20: note: 'mmu_has_feature' declared here
static inline bool mmu_has_feature(unsigned long feature)
^
arch/powerpc/lib/pmem.c:44:6: error: implicit declaration of function 'cpu_has_feature' [-Werror,-Wimplicit-function-declaration]
if (cpu_has_feature(CPU_FTR_ARCH_207S))
^
arch/powerpc/lib/pmem.c:50:6: error: implicit declaration of function 'cpu_has_feature' [-Werror,-Wimplicit-function-declaration]
if (cpu_has_feature(CPU_FTR_ARCH_207S))
^
arch/powerpc/lib/pmem.c:57:6: warning: no previous prototype for function 'arch_wb_cache_pmem' [-Wmissing-prototypes]
void arch_wb_cache_pmem(void *addr, size_t size)
^
arch/powerpc/lib/pmem.c:57:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
void arch_wb_cache_pmem(void *addr, size_t size)
^
static
arch/powerpc/lib/pmem.c:64:6: warning: no previous prototype for function 'arch_invalidate_pmem' [-Wmissing-prototypes]
void arch_invalidate_pmem(void *addr, size_t size)
^
arch/powerpc/lib/pmem.c:64:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
void arch_invalidate_pmem(void *addr, size_t size)
^
static
2 warnings and 3 errors generated.
vim +/cpu_has_feature +126 arch/powerpc/include/asm/cacheflush.h
113
114 #define copy_to_user_page(vma, page, vaddr, dst, src, len) \
115 do { \
116 memcpy(dst, src, len); \
117 flush_icache_user_range(vma, page, vaddr, len); \
118 } while (0)
119 #define copy_from_user_page(vma, page, vaddr, dst, src, len) \
120 memcpy(dst, src, len)
121
122
123 #define arch_pmem_flush_barrier arch_pmem_flush_barrier
124 static inline void arch_pmem_flush_barrier(void)
125 {
> 126 if (cpu_has_feature(CPU_FTR_ARCH_207S))
127 asm volatile(PPC_PHWSYNC ::: "memory");
128 }
129 #endif /* __KERNEL__ */
130
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33734 bytes --]
^ permalink raw reply
* Re: [PATCH v3 3/7] powerpc/pmem: Add flush routines using new pmem store and sync instruction
From: kbuild test robot @ 2020-05-30 0:47 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev, mpe, linux-nvdimm
Cc: kbuild-all, Aneesh Kumar K.V, clang-built-linux, oohall, alistair,
dan.j.williams
In-Reply-To: <20200519055502.128318-3-aneesh.kumar@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3057 bytes --]
Hi "Aneesh,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.7-rc7 next-20200529]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Aneesh-Kumar-K-V/powerpc-pmem-Restrict-papr_scm-to-P8-and-above/20200519-195350
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-randconfig-r016-20200529 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 2d068e534f1671459e1b135852c1b3c10502e929)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc cross compiling tool for clang build
# apt-get install binutils-powerpc-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> arch/powerpc/lib/pmem.c:44:6: error: implicit declaration of function 'cpu_has_feature' [-Werror,-Wimplicit-function-declaration]
if (cpu_has_feature(CPU_FTR_ARCH_207S))
^
arch/powerpc/lib/pmem.c:44:6: note: did you mean 'mmu_has_feature'?
arch/powerpc/include/asm/mmu.h:234:20: note: 'mmu_has_feature' declared here
static inline bool mmu_has_feature(unsigned long feature)
^
arch/powerpc/lib/pmem.c:50:6: error: implicit declaration of function 'cpu_has_feature' [-Werror,-Wimplicit-function-declaration]
if (cpu_has_feature(CPU_FTR_ARCH_207S))
^
arch/powerpc/lib/pmem.c:57:6: warning: no previous prototype for function 'arch_wb_cache_pmem' [-Wmissing-prototypes]
void arch_wb_cache_pmem(void *addr, size_t size)
^
arch/powerpc/lib/pmem.c:57:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
void arch_wb_cache_pmem(void *addr, size_t size)
^
static
arch/powerpc/lib/pmem.c:64:6: warning: no previous prototype for function 'arch_invalidate_pmem' [-Wmissing-prototypes]
void arch_invalidate_pmem(void *addr, size_t size)
^
arch/powerpc/lib/pmem.c:64:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
void arch_invalidate_pmem(void *addr, size_t size)
^
static
2 warnings and 2 errors generated.
vim +/cpu_has_feature +44 arch/powerpc/lib/pmem.c
41
42 static inline void clean_pmem_range(unsigned long start, unsigned long stop)
43 {
> 44 if (cpu_has_feature(CPU_FTR_ARCH_207S))
45 return __clean_pmem_range(start, stop);
46 }
47
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33734 bytes --]
^ permalink raw reply
* Re: [PATCH net] drivers/net/ibmvnic: Update VNIC protocol version reporting
From: David Miller @ 2020-05-30 0:21 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev, linuxppc-dev
In-Reply-To: <1590682757-3814-1-git-send-email-tlfalcon@linux.ibm.com>
From: Thomas Falcon <tlfalcon@linux.ibm.com>
Date: Thu, 28 May 2020 11:19:17 -0500
> VNIC protocol version is reported in big-endian format, but it
> is not byteswapped before logging. Fix that, and remove version
> comparison as only one protocol version exists at this time.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Applied, thanks.
^ permalink raw reply
* Re: [RFC][PATCH v3 1/5] sparc64: Fix asm/percpu.h build error
From: David Miller @ 2020-05-29 23:29 UTC (permalink / raw)
To: peterz
Cc: linux-s390, linuxppc-dev, bigeasy, x86, heiko.carstens,
linux-kernel, rostedt, a.darwish, sparclinux, tglx, will, mingo
In-Reply-To: <20200529214203.673108357@infradead.org>
From: Peter Zijlstra <peterz@infradead.org>
Date: Fri, 29 May 2020 23:35:51 +0200
> ../arch/sparc/include/asm/percpu_64.h:7:24: warning: call-clobbered register used for global register variable
> register unsigned long __local_per_cpu_offset asm("g5");
The "-ffixed-g5" option on the command line tells gcc that we are
using 'g5' as a fixed register, so some part of your build isn't using
the:
KBUILD_CFLAGS += -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare
from arch/sparc/Makefile for some reason.
^ permalink raw reply
* ppc64le and 32-bit LE userland compatibility
From: Will Springer @ 2020-05-29 19:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: libc-alpha, eery, daniel, musl, binutils, libc-dev
Hey all, a couple of us over in #talos-workstation on freenode have been
working on an effort to bring up a Linux PowerPC userland that runs in 32-bit
little-endian mode, aka ppcle. As far as we can tell, no ABI has ever been
designated for this (unless you count the patchset from a decade ago [1]), so
it's pretty much uncharted territory as far as Linux is concerned. We want to
sync up with libc and the relevant kernel folks to establish the best path
forward.
The practical application that drove these early developments (as you might
expect) is x86 emulation. The box86 project [2] implements a translation layer
for ia32 library calls to native architecture ones; this way, emulation
overhead is significantly reduced by relying on native libraries where
possible (libc, libGL, etc.) instead of emulating an entire x86 userspace.
box86 is primarily targeted at ARM, but it can be adapted to other
architectures—so long as they match ia32's 32-bit, little-endian nature. Hence
the need for a ppcle userland; modern POWER brought ppc64le as a supported
configuration, but without a 32-bit equivalent there is no option for a 32/64
multilib environment, as seen with ppc/ppc64 and arm/aarch64.
Surprisingly, beyond minor patching of gcc to get crosscompile going,
bootstrapping the initial userland was not much of a problem. The work has
been done on top of the Void Linux PowerPC project [3], and much of that is
now present in its source package tree [4].
The first issue with running the userland came from the ppc32 signal handler
forcing BE in the MSR, causing any 32LE process receiving a signal (such as a
shell receiving SIGCHLD) to terminate with SIGILL. This was trivially patched,
along with enabling the 32-bit vDSO on ppc64le kernels [5]. (Given that this
behavior has been in place since 2006, I don't think anyone has been using the
kernel in this state to run ppcle userlands.)
The next problem concerns the ABI more directly. The failure mode was `file`
surfacing EINVAL from pread64 when invoked on an ELF; pread64 was passed a
garbage value for `pos`, which didn't appear to be caused by anything in
`file`. Initially it seemed as though the 32-bit components of the arg were
getting swapped, and we made hacky fixes to glibc and musl to put them in the
"right order"; however, we weren't sure if that was the correct approach, or
if there were knock-on effects we didn't know about. So we found the relevant
compat code path in the kernel, at arch/powerpc/kernel/sys_ppc32.c, where
there exists this comment:
> /*
> * long long munging:
> * The 32 bit ABI passes long longs in an odd even register pair.
> */
It seems that the opposite is true in LE mode, and something is expecting long
longs to start on an even register. I realized this after I tried swapping hi/
lo `u32`s here and didn't see an improvement. I whipped up a patch [6] that
switches which syscalls use padding arguments depending on endianness, while
hopefully remaining tidy enough to be unobtrusive. (I took some liberties with
variable names/types so that the macro could be consistent.)
This was enough to fix up the `file` bug. I'm no seasoned kernel hacker,
though, and there is still concern over the right way to approach this,
whether it should live in the kernel or libc, etc. Frankly, I don't know the
ABI structure enough to understand why the register padding has to be
different in this case, or what lower-level component is responsible for it.
For comparison, I had a look at the mips tree, since it's bi-endian and has a
similar 32/64 situation. There is a macro conditional upon endianness that is
responsible for munging long longs; it uses __MIPSEB__ and __MIPSEL__ instead
of an if/else on the generic __LITTLE_ENDIAN__. Not sure what to make of that.
(It also simply swaps registers for LE, unlike what I did for ppc.)
Also worth noting is the one other outstanding bug, where the time-related
syscalls in the 32-bit vDSO seem to return garbage. It doesn't look like an
endian bug to me, and it doesn't affect standard syscalls (which is why if you
run `date` on musl it prints the correct time, unlike on glibc). The vDSO time
functions are implemented in ppc asm (arch/powerpc/kernel/vdso32/
gettimeofday.S), and I've never touched the stuff, so if anyone has a clue I'm
all ears.
Again, I'd appreciate feedback on the approach to take here, in order to
touch/special-case only the minimum necessary, while keeping the kernel/libc
folks happy.
Cheers,
Will [she/her]
(p.s. there is ancillary interest in a ppcle-native kernel as well; that's a
good deal more work and not the focus of this message at all, but it is a
topic of interest)
[1]: https://lwn.net/Articles/408845/
[2]: https://github.com/ptitSeb/box86
[3]: https://voidlinux-ppc.org/
[4]: https://github.com/void-ppc/void-packages
[5]: https://gist.github.com/eerykitty/01707dc6bca2be32b4c5e30d15d15dcf
[6]: https://gist.github.com/Skirmisher/02891c1a8cafa0ff18b2460933ef4f3c
^ permalink raw reply
* [powerpc:next-test 160/198] arch/powerpc/platforms/powernv/pci-ioda.c:1889:13: warning: function 'pnv_ioda_setup_bus_dma' is not needed and will not be emitted
From: kbuild test robot @ 2020-05-29 22:22 UTC (permalink / raw)
To: Oliver, O'Halloran,; +Cc: clang-built-linux, kbuild-all, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2998 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
head: e376ca093587eafd840bb0f9df04090e2a54249c
commit: dc3d8f85bb571c3640ebba24b82a527cf2cb3f24 [160/198] powerpc/powernv/pci: Re-work bus PE configuration
config: powerpc64-randconfig-r024-20200529 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 2d068e534f1671459e1b135852c1b3c10502e929)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install powerpc64 cross compiling tool for clang build
# apt-get install binutils-powerpc64-linux-gnu
git checkout dc3d8f85bb571c3640ebba24b82a527cf2cb3f24
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> arch/powerpc/platforms/powernv/pci-ioda.c:1889:13: warning: function 'pnv_ioda_setup_bus_dma' is not needed and will not be emitted [-Wunneeded-internal-declaration]
static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
^
1 warning generated.
vim +/pnv_ioda_setup_bus_dma +1889 arch/powerpc/platforms/powernv/pci-ioda.c
fe7e85c6f5ff63 Gavin Shan 2014-09-30 1888
5eada8a3f087df Alexey Kardashevskiy 2018-12-19 @1889 static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
74251fe21bfa93 Benjamin Herrenschmidt 2013-07-01 1890 {
74251fe21bfa93 Benjamin Herrenschmidt 2013-07-01 1891 struct pci_dev *dev;
74251fe21bfa93 Benjamin Herrenschmidt 2013-07-01 1892
74251fe21bfa93 Benjamin Herrenschmidt 2013-07-01 1893 list_for_each_entry(dev, &bus->devices, bus_list) {
b348aa65297659 Alexey Kardashevskiy 2015-06-05 1894 set_iommu_table_base(&dev->dev, pe->table_group.tables[0]);
0617fc0ca412b5 Christoph Hellwig 2019-02-13 1895 dev->dev.archdata.dma_offset = pe->tce_bypass_base;
dff4a39e880062 Gavin Shan 2014-07-15 1896
5c89a87d13d168 Alexey Kardashevskiy 2015-06-18 1897 if ((pe->flags & PNV_IODA_PE_BUS_ALL) && dev->subordinate)
5eada8a3f087df Alexey Kardashevskiy 2018-12-19 1898 pnv_ioda_setup_bus_dma(pe, dev->subordinate);
74251fe21bfa93 Benjamin Herrenschmidt 2013-07-01 1899 }
74251fe21bfa93 Benjamin Herrenschmidt 2013-07-01 1900 }
74251fe21bfa93 Benjamin Herrenschmidt 2013-07-01 1901
:::::: The code at line 1889 was first introduced by commit
:::::: 5eada8a3f087df74af1c2797770a3e2249374fe1 powerpc/iommu_api: Move IOMMU groups setup to a single place
:::::: TO: Alexey Kardashevskiy <aik@ozlabs.ru>
:::::: CC: Michael Ellerman <mpe@ellerman.id.au>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33114 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox