* Re: [PATCH V2 1/5] ocxl: Assign a register set to a Logical Partition
From: Frederic Barrat @ 2020-11-23 10:35 UTC (permalink / raw)
To: Christophe Lombard, linuxppc-dev, fbarrat, ajd
In-Reply-To: <20201120173241.59229-2-clombard@linux.vnet.ibm.com>
On 20/11/2020 18:32, Christophe Lombard wrote:
> Platform specific function to assign a register set to a Logical Partition.
> The "ibm,mmio-atsd" property, provided by the firmware, contains the 16
> base ATSD physical addresses (ATSD0 through ATSD15) of the set of MMIO
> registers (XTS MMIO ATSDx LPARID/AVA/launch/status register).
>
> For the time being, the ATSD0 set of registers is used by default.
>
> Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/pnv-ocxl.h | 3 ++
> arch/powerpc/platforms/powernv/ocxl.c | 48 +++++++++++++++++++++++++++
> 2 files changed, 51 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/pnv-ocxl.h b/arch/powerpc/include/asm/pnv-ocxl.h
> index d37ededca3ee..3f38aed7100c 100644
> --- a/arch/powerpc/include/asm/pnv-ocxl.h
> +++ b/arch/powerpc/include/asm/pnv-ocxl.h
> @@ -28,4 +28,7 @@ int pnv_ocxl_spa_setup(struct pci_dev *dev, void *spa_mem, int PE_mask, void **p
> void pnv_ocxl_spa_release(void *platform_data);
> int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int pe_handle);
>
> +int pnv_ocxl_map_lpar(struct pci_dev *dev, uint64_t lparid,
> + uint64_t lpcr, void __iomem **arva);
> +void pnv_ocxl_unmap_lpar(void __iomem **arva);
> #endif /* _ASM_PNV_OCXL_H */
> diff --git a/arch/powerpc/platforms/powernv/ocxl.c b/arch/powerpc/platforms/powernv/ocxl.c
> index ecdad219d704..bc20cf867900 100644
> --- a/arch/powerpc/platforms/powernv/ocxl.c
> +++ b/arch/powerpc/platforms/powernv/ocxl.c
> @@ -483,3 +483,51 @@ int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int pe_handle)
> return rc;
> }
> EXPORT_SYMBOL_GPL(pnv_ocxl_spa_remove_pe_from_cache);
> +
> +int pnv_ocxl_map_lpar(struct pci_dev *dev, uint64_t lparid,
> + uint64_t lpcr, void __iomem **arva)
> +{
> + struct pci_controller *hose = pci_bus_to_host(dev->bus);
> + struct pnv_phb *phb = hose->private_data;
> + u64 mmio_atsd;
> + int rc;
> +
> + /* ATSD physical address.
> + * ATSD LAUNCH register: write access initiates a shoot down to
> + * initiate the TLB Invalidate command.
> + */
> + rc = of_property_read_u64_index(hose->dn, "ibm,mmio-atsd",
> + 0, &mmio_atsd);
> + if (rc) {
> + dev_info(&dev->dev, "No available ATSD found\n");
> + return rc;
> + }
> +
> + /* Assign a register set to a Logical Partition and MMIO ATSD
> + * LPARID register to the required value.
> + */
> + if (mmio_atsd)
If we don't have the "ibm,mmio-atsd", i.e on P9, then we've already
exited above. So why not consider mmio_atsd as an error?
> + rc = opal_npu_map_lpar(phb->opal_id, pci_dev_id(dev),
> + lparid, lpcr);
> + if (rc) {
> + dev_err(&dev->dev, "Error mapping device to LPAR: %d\n", rc);
> + return rc;
> + }
> +
> + if (mmio_atsd) {
Same here
> + *arva = ioremap(mmio_atsd, 24);
> + if (!(*arva)) {
> + dev_warn(&dev->dev, "ioremap failed - mmio_atsd: %#llx\n", mmio_atsd);
> + rc = -ENOMEM;
> + }
> + }
> +
> + return rc;
> +}
> +EXPORT_SYMBOL_GPL(pnv_ocxl_map_lpar);
> +
> +void pnv_ocxl_unmap_lpar(void __iomem **arva)
The arva argument doesn't need to be a double pointer. Void * is enough.
Fred
> +{
> + iounmap(*arva);
> +}
> +EXPORT_SYMBOL_GPL(pnv_ocxl_unmap_lpar);
>
^ permalink raw reply
* Re: [PATCH V2 2/5] ocxl: Initiate a TLB invalidate command
From: Frederic Barrat @ 2020-11-23 10:37 UTC (permalink / raw)
To: Christophe Lombard, linuxppc-dev, fbarrat, ajd
In-Reply-To: <20201120173241.59229-3-clombard@linux.vnet.ibm.com>
On 20/11/2020 18:32, Christophe Lombard wrote:
> When a TLB Invalidate is required for the Logical Partition, the following
> sequence has to be performed:
>
> 1. Load MMIO ATSD AVA register with the necessary value, if required.
> 2. Write the MMIO ATSD launch register to initiate the TLB Invalidate
> command.
> 3. Poll the MMIO ATSD status register to determine when the TLB Invalidate
> has been completed.
>
> Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
> ---
> arch/powerpc/include/asm/pnv-ocxl.h | 50 ++++++++++++++++++++++++
> arch/powerpc/platforms/powernv/ocxl.c | 55 +++++++++++++++++++++++++++
> 2 files changed, 105 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/pnv-ocxl.h b/arch/powerpc/include/asm/pnv-ocxl.h
> index 3f38aed7100c..9c90e87e7659 100644
> --- a/arch/powerpc/include/asm/pnv-ocxl.h
> +++ b/arch/powerpc/include/asm/pnv-ocxl.h
> @@ -3,12 +3,59 @@
> #ifndef _ASM_PNV_OCXL_H
> #define _ASM_PNV_OCXL_H
>
> +#include <linux/bitfield.h>
> #include <linux/pci.h>
>
> #define PNV_OCXL_TL_MAX_TEMPLATE 63
> #define PNV_OCXL_TL_BITS_PER_RATE 4
> #define PNV_OCXL_TL_RATE_BUF_SIZE ((PNV_OCXL_TL_MAX_TEMPLATE+1) * PNV_OCXL_TL_BITS_PER_RATE / 8)
>
> +#define PNV_OCXL_ATSD_TIMEOUT 1
> +
> +/* TLB Management Instructions */
> +#define PNV_OCXL_ATSD_LNCH 0x00
> +/* Radix Invalidate */
> +#define PNV_OCXL_ATSD_LNCH_R PPC_BIT(0)
> +/* Radix Invalidation Control
> + * 0b00 Just invalidate TLB.
> + * 0b01 Invalidate just Page Walk Cache.
> + * 0b10 Invalidate TLB, Page Walk Cache, and any
> + * caching of Partition and Process Table Entries.
> + */
> +#define PNV_OCXL_ATSD_LNCH_RIC PPC_BITMASK(1, 2)
> +/* Number and Page Size of translations to be invalidated */
> +#define PNV_OCXL_ATSD_LNCH_LP PPC_BITMASK(3, 10)
> +/* Invalidation Criteria
> + * 0b00 Invalidate just the target VA.
> + * 0b01 Invalidate matching PID.
> + */
> +#define PNV_OCXL_ATSD_LNCH_IS PPC_BITMASK(11, 12)
> +/* 0b1: Process Scope, 0b0: Partition Scope */
> +#define PNV_OCXL_ATSD_LNCH_PRS PPC_BIT(13)
> +/* Invalidation Flag */
> +#define PNV_OCXL_ATSD_LNCH_B PPC_BIT(14)
> +/* Actual Page Size to be invalidated
> + * 000 4KB
> + * 101 64KB
> + * 001 2MB
> + * 010 1GB
> + */
> +#define PNV_OCXL_ATSD_LNCH_AP PPC_BITMASK(15, 17)
> +/* Defines the large page select
> + * L=0b0 for 4KB pages
> + * L=0b1 for large pages)
> + */
> +#define PNV_OCXL_ATSD_LNCH_L PPC_BIT(18)
> +/* Process ID */
> +#define PNV_OCXL_ATSD_LNCH_PID PPC_BITMASK(19, 38)
> +/* NoFlush – Assumed to be 0b0 */
> +#define PNV_OCXL_ATSD_LNCH_F PPC_BIT(39)
> +#define PNV_OCXL_ATSD_LNCH_OCAPI_SLBI PPC_BIT(40)
> +#define PNV_OCXL_ATSD_LNCH_OCAPI_SINGLETON PPC_BIT(41)
> +#define PNV_OCXL_ATSD_AVA 0x08
> +#define PNV_OCXL_ATSD_AVA_AVA PPC_BITMASK(0, 51)
> +#define PNV_OCXL_ATSD_STAT 0x10
> +
> int pnv_ocxl_get_actag(struct pci_dev *dev, u16 *base, u16 *enabled, u16 *supported);
> int pnv_ocxl_get_pasid_count(struct pci_dev *dev, int *count);
>
> @@ -31,4 +78,7 @@ int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int pe_handle);
> int pnv_ocxl_map_lpar(struct pci_dev *dev, uint64_t lparid,
> uint64_t lpcr, void __iomem **arva);
> void pnv_ocxl_unmap_lpar(void __iomem **arva);
> +void pnv_ocxl_tlb_invalidate(void __iomem **arva,
> + unsigned long pid,
> + unsigned long addr);
> #endif /* _ASM_PNV_OCXL_H */
> diff --git a/arch/powerpc/platforms/powernv/ocxl.c b/arch/powerpc/platforms/powernv/ocxl.c
> index bc20cf867900..07878496954b 100644
> --- a/arch/powerpc/platforms/powernv/ocxl.c
> +++ b/arch/powerpc/platforms/powernv/ocxl.c
> @@ -531,3 +531,58 @@ void pnv_ocxl_unmap_lpar(void __iomem **arva)
> iounmap(*arva);
> }
> EXPORT_SYMBOL_GPL(pnv_ocxl_unmap_lpar);
> +
> +void pnv_ocxl_tlb_invalidate(void __iomem **arva,
Similarly to the previous patch, there's no reason why arva should be a
double-pointer.
> + unsigned long pid,
> + unsigned long addr)
> +{
> + unsigned long timeout = jiffies + (HZ * PNV_OCXL_ATSD_TIMEOUT);
> + uint64_t val = 0ull;
> + int pend;
> +
> + if (!(*arva))
> + return;
> +
> + if (addr) {
> + /* load Abbreviated Virtual Address register with
> + * the necessary value
> + */
> + val |= FIELD_PREP(PNV_OCXL_ATSD_AVA_AVA, addr >> (63-51));
> + out_be64(*arva + PNV_OCXL_ATSD_AVA, val);
> + }
> +
> + /* Write access initiates a shoot down to initiate the
> + * TLB Invalidate command
> + */
> + val = PNV_OCXL_ATSD_LNCH_R;
> + if (addr) {
> + val |= FIELD_PREP(PNV_OCXL_ATSD_LNCH_RIC, 0b00);
> + val |= FIELD_PREP(PNV_OCXL_ATSD_LNCH_IS, 0b00);
> + } else {
> + val |= FIELD_PREP(PNV_OCXL_ATSD_LNCH_RIC, 0b10);
> + val |= FIELD_PREP(PNV_OCXL_ATSD_LNCH_IS, 0b01);
> + val |= PNV_OCXL_ATSD_LNCH_OCAPI_SINGLETON;
> + }
> + val |= PNV_OCXL_ATSD_LNCH_PRS;
> + val |= FIELD_PREP(PNV_OCXL_ATSD_LNCH_AP, 0b101);
So we hard code a page size of 64k. The mmu notifier loops over
PAGE_SIZE. It would be cleaner to pass the page size as an argument and
code AP based on it.
Fred
> + val |= FIELD_PREP(PNV_OCXL_ATSD_LNCH_PID, pid);
> + out_be64(*arva + PNV_OCXL_ATSD_LNCH, val);
> +
> + /* Poll the ATSD status register to determine when the
> + * TLB Invalidate has been completed.
> + */
> + val = in_be64(*arva + PNV_OCXL_ATSD_STAT);
> + pend = val >> 63;
> +
> + while (pend) {
> + if (time_after_eq(jiffies, timeout)) {
> + pr_err("%s - Timeout while reading XTS MMIO ATSD status register (val=%#llx, pidr=0x%lx)\n",
> + __func__, val, pid);
> + return;
> + }
> + cpu_relax();
> + val = in_be64(*arva + PNV_OCXL_ATSD_STAT);
> + pend = val >> 63;
> + }
> +}
> +EXPORT_SYMBOL_GPL(pnv_ocxl_tlb_invalidate);
>
^ permalink raw reply
* Re: [PATCH V2 3/5] ocxl: Update the Process Element Entry
From: Frederic Barrat @ 2020-11-23 10:38 UTC (permalink / raw)
To: Christophe Lombard, linuxppc-dev, fbarrat, ajd
In-Reply-To: <20201120173241.59229-4-clombard@linux.vnet.ibm.com>
On 20/11/2020 18:32, Christophe Lombard wrote:
> To complete the MMIO based mechanism, the fields: PASID, bus, device and
> function of the Process Element Entry have to be filled. (See
> OpenCAPI Power Platform Architecture document)
>
> Hypervisor Process Element Entry
> Word
> 0 1 .... 7 8 ...... 12 13 ..15 16.... 19 20 ........... 31
> 0 OSL Configuration State (0:31)
> 1 OSL Configuration State (32:63)
> 2 PASID | Reserved
> 3 Bus | Device |Function | Reserved
> 4 Reserved
> 5 Reserved
> 6 ....
>
> Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
> ---
> drivers/misc/ocxl/context.c | 4 +++-
> drivers/misc/ocxl/link.c | 4 +++-
> drivers/misc/ocxl/ocxl_internal.h | 4 +++-
> drivers/scsi/cxlflash/ocxl_hw.c | 6 ++++--
> include/misc/ocxl.h | 2 +-
> 5 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/misc/ocxl/context.c b/drivers/misc/ocxl/context.c
> index c21f65a5c762..9eb0d93b01c6 100644
> --- a/drivers/misc/ocxl/context.c
> +++ b/drivers/misc/ocxl/context.c
> @@ -70,6 +70,7 @@ int ocxl_context_attach(struct ocxl_context *ctx, u64 amr, struct mm_struct *mm)
> {
> int rc;
> unsigned long pidr = 0;
> + struct pci_dev *dev;
>
> // Locks both status & tidr
> mutex_lock(&ctx->status_mutex);
> @@ -81,8 +82,9 @@ int ocxl_context_attach(struct ocxl_context *ctx, u64 amr, struct mm_struct *mm)
> if (mm)
> pidr = mm->context.id;
>
> + dev = to_pci_dev(ctx->afu->fn->dev.parent);
> rc = ocxl_link_add_pe(ctx->afu->fn->link, ctx->pasid, pidr, ctx->tidr,
> - amr, mm, xsl_fault_error, ctx);
> + amr, pci_dev_id(dev), mm, xsl_fault_error, ctx);
> if (rc)
> goto out;
>
> diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
> index fd73d3bc0eb6..20444db8a2bb 100644
> --- a/drivers/misc/ocxl/link.c
> +++ b/drivers/misc/ocxl/link.c
> @@ -494,7 +494,7 @@ static u64 calculate_cfg_state(bool kernel)
> }
>
> int ocxl_link_add_pe(void *link_handle, int pasid, u32 pidr, u32 tidr,
> - u64 amr, struct mm_struct *mm,
> + u64 amr, u64 bdf, struct mm_struct *mm,
bdf could/should be a u16, since that's per the PCI spec.
Fred
> void (*xsl_err_cb)(void *data, u64 addr, u64 dsisr),
> void *xsl_err_data)
> {
> @@ -529,6 +529,8 @@ int ocxl_link_add_pe(void *link_handle, int pasid, u32 pidr, u32 tidr,
>
> memset(pe, 0, sizeof(struct ocxl_process_element));
> pe->config_state = cpu_to_be64(calculate_cfg_state(pidr == 0));
> + pe->pasid = cpu_to_be32(pasid << (31 - 19));
> + pe->bdf = cpu_to_be32(bdf << (31 - 15));
> pe->lpid = cpu_to_be32(mfspr(SPRN_LPID));
> pe->pid = cpu_to_be32(pidr);
> pe->tid = cpu_to_be32(tidr);
> diff --git a/drivers/misc/ocxl/ocxl_internal.h b/drivers/misc/ocxl/ocxl_internal.h
> index 0bad0a123af6..c9ce2af21d6f 100644
> --- a/drivers/misc/ocxl/ocxl_internal.h
> +++ b/drivers/misc/ocxl/ocxl_internal.h
> @@ -84,7 +84,9 @@ struct ocxl_context {
>
> struct ocxl_process_element {
> __be64 config_state;
> - __be32 reserved1[11];
> + __be32 pasid;
> + __be32 bdf;
> + __be32 reserved1[9];
> __be32 lpid;
> __be32 tid;
> __be32 pid;
> diff --git a/drivers/scsi/cxlflash/ocxl_hw.c b/drivers/scsi/cxlflash/ocxl_hw.c
> index e4e0d767b98e..244fc27215dc 100644
> --- a/drivers/scsi/cxlflash/ocxl_hw.c
> +++ b/drivers/scsi/cxlflash/ocxl_hw.c
> @@ -329,6 +329,7 @@ static int start_context(struct ocxlflash_context *ctx)
> struct ocxl_hw_afu *afu = ctx->hw_afu;
> struct ocxl_afu_config *acfg = &afu->acfg;
> void *link_token = afu->link_token;
> + struct pci_dev *pdev = afu->pdev;
> struct device *dev = afu->dev;
> bool master = ctx->master;
> struct mm_struct *mm;
> @@ -360,8 +361,9 @@ static int start_context(struct ocxlflash_context *ctx)
> mm = current->mm;
> }
>
> - rc = ocxl_link_add_pe(link_token, ctx->pe, pid, 0, 0, mm,
> - ocxlflash_xsl_fault, ctx);
> + rc = ocxl_link_add_pe(link_token, ctx->pe, pid, 0, 0,
> + pci_dev_id(pdev), mm, ocxlflash_xsl_fault,
> + ctx);
> if (unlikely(rc)) {
> dev_err(dev, "%s: ocxl_link_add_pe failed rc=%d\n",
> __func__, rc);
> diff --git a/include/misc/ocxl.h b/include/misc/ocxl.h
> index e013736e275d..d0f101f428dd 100644
> --- a/include/misc/ocxl.h
> +++ b/include/misc/ocxl.h
> @@ -447,7 +447,7 @@ void ocxl_link_release(struct pci_dev *dev, void *link_handle);
> * defined
> */
> int ocxl_link_add_pe(void *link_handle, int pasid, u32 pidr, u32 tidr,
> - u64 amr, struct mm_struct *mm,
> + u64 amr, u64 bdf, struct mm_struct *mm,
> void (*xsl_err_cb)(void *data, u64 addr, u64 dsisr),
> void *xsl_err_data);
>
^ permalink raw reply
* Re: [PATCH V2 4/5] ocxl: Add mmu notifier
From: Frederic Barrat @ 2020-11-23 10:40 UTC (permalink / raw)
To: Christophe Lombard, linuxppc-dev, fbarrat, ajd
In-Reply-To: <20201120173241.59229-5-clombard@linux.vnet.ibm.com>
On 20/11/2020 18:32, Christophe Lombard wrote:
> Add invalidate_range mmu notifier, when required (ATSD access of MMIO
> registers is available), to initiate TLB invalidation commands.
> For the time being, the ATSD0 set of registers is used by default.
>
> The pasid and bdf values have to be configured in the Process Element
> Entry.
> The PEE must be set up to match the BDF/PASID of the AFU.
>
> Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
> ---
> drivers/misc/ocxl/link.c | 58 +++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 57 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
> index 20444db8a2bb..100bdfe9ec37 100644
> --- a/drivers/misc/ocxl/link.c
> +++ b/drivers/misc/ocxl/link.c
> @@ -2,8 +2,10 @@
> // Copyright 2017 IBM Corp.
> #include <linux/sched/mm.h>
> #include <linux/mutex.h>
> +#include <linux/mm.h>
> #include <linux/mm_types.h>
> #include <linux/mmu_context.h>
> +#include <linux/mmu_notifier.h>
> #include <asm/copro.h>
> #include <asm/pnv-ocxl.h>
> #include <asm/xive.h>
> @@ -33,6 +35,7 @@
>
> #define SPA_PE_VALID 0x80000000
>
> +struct ocxl_link;
>
> struct pe_data {
> struct mm_struct *mm;
> @@ -41,6 +44,8 @@ struct pe_data {
> /* opaque pointer to be passed to the above callback */
> void *xsl_err_data;
> struct rcu_head rcu;
> + struct ocxl_link *link;
> + struct mmu_notifier mmu_notifier;
> };
>
> struct spa {
> @@ -83,6 +88,8 @@ struct ocxl_link {
> int domain;
> int bus;
> int dev;
> + void __iomem *arva; /* ATSD register virtual address */
> + spinlock_t atsd_lock; /* to serialize shootdowns */
> atomic_t irq_available;
> struct spa *spa;
> void *platform_data;
> @@ -403,6 +410,11 @@ static int alloc_link(struct pci_dev *dev, int PE_mask, struct ocxl_link **out_l
> if (rc)
> goto err_xsl_irq;
>
> + rc = pnv_ocxl_map_lpar(dev, mfspr(SPRN_LPID), 0,
> + &link->arva);
> + if (!rc)
> + spin_lock_init(&link->atsd_lock);
> +
We could use a comment to say that if arva = 0, then we don't need mmio
shootdowns and we rely on hardware snooping.
Also, we could always initialize the spin lock, it doesn't hurt and make
the code more readable.
Fred
> *out_link = link;
> return 0;
>
> @@ -454,6 +466,11 @@ static void release_xsl(struct kref *ref)
> {
> struct ocxl_link *link = container_of(ref, struct ocxl_link, ref);
>
> + if (link->arva) {
> + pnv_ocxl_unmap_lpar(&link->arva);
> + link->arva = NULL;
> + }
> +
> list_del(&link->list);
> /* call platform code before releasing data */
> pnv_ocxl_spa_release(link->platform_data);
> @@ -470,6 +487,26 @@ void ocxl_link_release(struct pci_dev *dev, void *link_handle)
> }
> EXPORT_SYMBOL_GPL(ocxl_link_release);
>
> +static void invalidate_range(struct mmu_notifier *mn,
> + struct mm_struct *mm,
> + unsigned long start, unsigned long end)
> +{
> + struct pe_data *pe_data = container_of(mn, struct pe_data, mmu_notifier);
> + struct ocxl_link *link = pe_data->link;
> + unsigned long addr, pid, page_size = PAGE_SIZE;
> +
> + pid = mm->context.id;
> +
> + spin_lock(&link->atsd_lock);
> + for (addr = start; addr < end; addr += page_size)
> + pnv_ocxl_tlb_invalidate(&link->arva, pid, addr);
> + spin_unlock(&link->atsd_lock);
> +}
> +
> +static const struct mmu_notifier_ops ocxl_mmu_notifier_ops = {
> + .invalidate_range = invalidate_range,
> +};
> +
> static u64 calculate_cfg_state(bool kernel)
> {
> u64 state;
> @@ -526,6 +563,8 @@ int ocxl_link_add_pe(void *link_handle, int pasid, u32 pidr, u32 tidr,
> pe_data->mm = mm;
> pe_data->xsl_err_cb = xsl_err_cb;
> pe_data->xsl_err_data = xsl_err_data;
> + pe_data->link = link;
> + pe_data->mmu_notifier.ops = &ocxl_mmu_notifier_ops;
>
> memset(pe, 0, sizeof(struct ocxl_process_element));
> pe->config_state = cpu_to_be64(calculate_cfg_state(pidr == 0));
> @@ -542,8 +581,16 @@ int ocxl_link_add_pe(void *link_handle, int pasid, u32 pidr, u32 tidr,
> * by the nest MMU. If we have a kernel context, TLBIs are
> * already global.
> */
> - if (mm)
> + if (mm) {
> mm_context_add_copro(mm);
> + if (link->arva) {
> + /* Use MMIO registers for the TLB Invalidate
> + * operations.
> + */
> + mmu_notifier_register(&pe_data->mmu_notifier, mm);
> + }
> + }
> +
> /*
> * Barrier is to make sure PE is visible in the SPA before it
> * is used by the device. It also helps with the global TLBI
> @@ -674,6 +721,15 @@ int ocxl_link_remove_pe(void *link_handle, int pasid)
> WARN(1, "Couldn't find pe data when removing PE\n");
> } else {
> if (pe_data->mm) {
> + if (link->arva) {
> + mmu_notifier_unregister(&pe_data->mmu_notifier,
> + pe_data->mm);
> + spin_lock(&link->atsd_lock);
> + pnv_ocxl_tlb_invalidate(&link->arva,
> + pe_data->mm->context.id,
> + 0ull);
> + spin_unlock(&link->atsd_lock);
> + }
> mm_context_remove_copro(pe_data->mm);
> mmdrop(pe_data->mm);
> }
>
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Fix crash with 'is_sier_available' when pmu is not set
From: Sachin Sant @ 2020-11-23 10:55 UTC (permalink / raw)
To: Athira Rajeev; +Cc: maddy, linuxppc-dev
In-Reply-To: <1606124997-3358-1-git-send-email-atrajeev@linux.vnet.ibm.com>
> When perf record session started with "-I" option, capture registers
> via intr-regs, on each sample ‘is_sier_available()'i is called to check
> for the SIER ( Sample Instruction Event Register) availability in the
> platform. This function in core-book3s access 'ppmu->flags'. If platform
> specific pmu driver is not registered, ppmu is set to null and accessing
> its members results in crash. Patch fixes this by returning false in
> 'is_sier_available()' if 'ppmu' is not set.
>
> Fixes: 333804dc3b7a ("powerpc/perf: Update perf_regs structure to include SIER")
> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Thanks
-Sachin
^ permalink raw reply
* Re: [PATCH 1/3] perf/core: Flush PMU internal buffers for per-CPU events
From: Michael Ellerman @ 2020-11-23 11:00 UTC (permalink / raw)
To: Namhyung Kim, Liang, Kan
Cc: Ian Rogers, Andi Kleen, Peter Zijlstra, linuxppc-dev,
linux-kernel, Stephane Eranian, Paul Mackerras,
Arnaldo Carvalho de Melo, Jiri Olsa, Ingo Molnar, Gabriel Marin
In-Reply-To: <CAM9d7chbQE=zkqYsNFMv+uWEYWdXcGD=fNYT_R2ondwR5zVvaQ@mail.gmail.com>
Namhyung Kim <namhyung@kernel.org> writes:
> Hi Peter and Kan,
>
> (Adding PPC folks)
>
> On Tue, Nov 17, 2020 at 2:01 PM Namhyung Kim <namhyung@kernel.org> wrote:
>>
>> Hello,
>>
>> On Thu, Nov 12, 2020 at 4:54 AM Liang, Kan <kan.liang@linux.intel.com> wrote:
>> >
>> >
>> >
>> > On 11/11/2020 11:25 AM, Peter Zijlstra wrote:
>> > > On Mon, Nov 09, 2020 at 09:49:31AM -0500, Liang, Kan wrote:
>> > >
>> > >> - When the large PEBS was introduced (9c964efa4330), the sched_task() should
>> > >> be invoked to flush the PEBS buffer in each context switch. However, The
>> > >> perf_sched_events in account_event() is not updated accordingly. The
>> > >> perf_event_task_sched_* never be invoked for a pure per-CPU context. Only
>> > >> per-task event works.
>> > >> At that time, the perf_pmu_sched_task() is outside of
>> > >> perf_event_context_sched_in/out. It means that perf has to double
>> > >> perf_pmu_disable() for per-task event.
>> > >
>> > >> - The patch 1 tries to fix broken per-CPU events. The CPU context cannot be
>> > >> retrieved from the task->perf_event_ctxp. So it has to be tracked in the
>> > >> sched_cb_list. Yes, the code is very similar to the original codes, but it
>> > >> is actually the new code for per-CPU events. The optimization for per-task
>> > >> events is still kept.
>> > >> For the case, which has both a CPU context and a task context, yes, the
>> > >> __perf_pmu_sched_task() in this patch is not invoked. Because the
>> > >> sched_task() only need to be invoked once in a context switch. The
>> > >> sched_task() will be eventually invoked in the task context.
>> > >
>> > > The thing is; your first two patches rely on PERF_ATTACH_SCHED_CB and
>> > > only set that for large pebs. Are you sure the other users (Intel LBR
>> > > and PowerPC BHRB) don't need it?
>> >
>> > I didn't set it for LBR, because the perf_sched_events is always enabled
>> > for LBR. But, yes, we should explicitly set the PERF_ATTACH_SCHED_CB
>> > for LBR.
>> >
>> > if (has_branch_stack(event))
>> > inc = true;
>> >
>> > >
>> > > If they indeed do not require the pmu::sched_task() callback for CPU
>> > > events, then I still think the whole perf_sched_cb_{inc,dec}() interface
>> >
>> > No, LBR requires the pmu::sched_task() callback for CPU events.
>> >
>> > Now, The LBR registers have to be reset in sched in even for CPU events.
>> >
>> > To fix the shorter LBR callstack issue for CPU events, we also need to
>> > save/restore LBRs in pmu::sched_task().
>> > https://lore.kernel.org/lkml/1578495789-95006-4-git-send-email-kan.liang@linux.intel.com/
>> >
>> > > is confusing at best.
>> > >
>> > > Can't we do something like this instead?
>> > >
>> > I think the below patch may have two issues.
>> > - PERF_ATTACH_SCHED_CB is required for LBR (maybe PowerPC BHRB as well) now.
>> > - We may disable the large PEBS later if not all PEBS events support
>> > large PEBS. The PMU need a way to notify the generic code to decrease
>> > the nr_sched_task.
>>
>> Any updates on this? I've reviewed and tested Kan's patches
>> and they all look good.
>>
>> Maybe we can talk to PPC folks to confirm the BHRB case?
>
> Can we move this forward? I saw patch 3/3 also adds PERF_ATTACH_SCHED_CB
> for PowerPC too. But it'd be nice if ppc folks can confirm the change.
Sorry I've read the whole thread, but I'm still not entirely sure I
understand the question.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Fix crash with 'is_sier_available' when pmu is not set
From: Michael Ellerman @ 2020-11-23 11:19 UTC (permalink / raw)
To: Athira Rajeev; +Cc: sachinp, maddy, linuxppc-dev
In-Reply-To: <1606124997-3358-1-git-send-email-atrajeev@linux.vnet.ibm.com>
Hi Athira,
Athira Rajeev <atrajeev@linux.vnet.ibm.com> writes:
> On systems without any platform specific PMU driver support registered or
> Generic Compat PMU support registered,
The compat PMU is registered just like other PMUs, so I don't see how we
can crash like this if the compat PMU is active?
ie. if we're using the compat PMU then ppmu will be non-NULL and point
to generic_compat_pmu.
> running 'perf record' with
> —intr-regs will crash ( perf record -I <workload> ).
>
> The relevant portion from crash logs and Call Trace:
>
> Unable to handle kernel paging request for data at address 0x00000068
> Faulting instruction address: 0xc00000000013eb18
> Oops: Kernel access of bad area, sig: 11 [#1]
> CPU: 2 PID: 13435 Comm: kill Kdump: loaded Not tainted 4.18.0-193.el8.ppc64le #1
> NIP: c00000000013eb18 LR: c000000000139f2c CTR: c000000000393d80
> REGS: c0000004a07ab4f0 TRAP: 0300 Not tainted (4.18.0-193.el8.ppc64le)
> NIP [c00000000013eb18] is_sier_available+0x18/0x30
> LR [c000000000139f2c] perf_reg_value+0x6c/0xb0
> Call Trace:
> [c0000004a07ab770] [c0000004a07ab7c8] 0xc0000004a07ab7c8 (unreliable)
> [c0000004a07ab7a0] [c0000000003aa77c] perf_output_sample+0x60c/0xac0
> [c0000004a07ab840] [c0000000003ab3f0] perf_event_output_forward+0x70/0xb0
> [c0000004a07ab8c0] [c00000000039e208] __perf_event_overflow+0x88/0x1a0
> [c0000004a07ab910] [c00000000039e42c] perf_swevent_hrtimer+0x10c/0x1d0
> [c0000004a07abc50] [c000000000228b9c] __hrtimer_run_queues+0x17c/0x480
> [c0000004a07abcf0] [c00000000022aaf4] hrtimer_interrupt+0x144/0x520
> [c0000004a07abdd0] [c00000000002a864] timer_interrupt+0x104/0x2f0
> [c0000004a07abe30] [c0000000000091c4] decrementer_common+0x114/0x120
>
> When perf record session started with "-I" option, capture registers
^
is
> via intr-regs,
"intr-regs" is just the full name for the -I option, so that kind of
repeats itself.
> on each sample ‘is_sier_available()'i is called to check
^
extra i
The single quotes around is_sier_available() aren't necessary IMO.
> for the SIER ( Sample Instruction Event Register) availability in the
^
stray space
> platform. This function in core-book3s access 'ppmu->flags'. If platform
^ ^
es a
> specific pmu driver is not registered, ppmu is set to null and accessing
^ ^
PMU NULL
> its members results in crash. Patch fixes this by returning false in
^
a
> 'is_sier_available()' if 'ppmu' is not set.
Use the imperative mood for the last sentence which says what the patch
does:
Fix the crash by returning false in is_sier_available() if ppmu is not set.
> Fixes: 333804dc3b7a ("powerpc/perf: Update perf_regs structure to include SIER")
> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> ---
> arch/powerpc/perf/core-book3s.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index 08643cb..1de4770 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -137,6 +137,9 @@ static void pmao_restore_workaround(bool ebb) { }
>
> bool is_sier_available(void)
> {
> + if (!ppmu)
> + return false;
> +
> if (ppmu->flags & PPMU_HAS_SIER)
> return true;
>
> --
> 1.8.3.1
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Fix crash with 'is_sier_available' when pmu is not set
From: Athira Rajeev @ 2020-11-23 13:32 UTC (permalink / raw)
To: Michael Ellerman; +Cc: sachinp, Madhavan Srinivasan, linuxppc-dev
In-Reply-To: <877dqc1ftj.fsf@mpe.ellerman.id.au>
> On 23-Nov-2020, at 4:49 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Hi Athira,
>
> Athira Rajeev <atrajeev@linux.vnet.ibm.com> writes:
>> On systems without any platform specific PMU driver support registered or
>> Generic Compat PMU support registered,
>
> The compat PMU is registered just like other PMUs, so I don't see how we
> can crash like this if the compat PMU is active?
>
> ie. if we're using the compat PMU then ppmu will be non-NULL and point
> to generic_compat_pmu.
Hi Michael,
Thanks for checking the patch.
Crash happens on systems which neither has compat PMU support registered nor
has Platform specific PMU. This happens when the distro do not have either the PMU
driver support for that platform or the generic "compat-mode" performance monitoring
driver support.
So in such cases since compat PMU is in-active, ppmu is not set and
results in crash. Sorry for the confusion with my first line. I will correct it.
>
>> running 'perf record' with
>> —intr-regs will crash ( perf record -I <workload> ).
>>
>> The relevant portion from crash logs and Call Trace:
>>
>> Unable to handle kernel paging request for data at address 0x00000068
>> Faulting instruction address: 0xc00000000013eb18
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> CPU: 2 PID: 13435 Comm: kill Kdump: loaded Not tainted 4.18.0-193.el8.ppc64le #1
>> NIP: c00000000013eb18 LR: c000000000139f2c CTR: c000000000393d80
>> REGS: c0000004a07ab4f0 TRAP: 0300 Not tainted (4.18.0-193.el8.ppc64le)
>> NIP [c00000000013eb18] is_sier_available+0x18/0x30
>> LR [c000000000139f2c] perf_reg_value+0x6c/0xb0
>> Call Trace:
>> [c0000004a07ab770] [c0000004a07ab7c8] 0xc0000004a07ab7c8 (unreliable)
>> [c0000004a07ab7a0] [c0000000003aa77c] perf_output_sample+0x60c/0xac0
>> [c0000004a07ab840] [c0000000003ab3f0] perf_event_output_forward+0x70/0xb0
>> [c0000004a07ab8c0] [c00000000039e208] __perf_event_overflow+0x88/0x1a0
>> [c0000004a07ab910] [c00000000039e42c] perf_swevent_hrtimer+0x10c/0x1d0
>> [c0000004a07abc50] [c000000000228b9c] __hrtimer_run_queues+0x17c/0x480
>> [c0000004a07abcf0] [c00000000022aaf4] hrtimer_interrupt+0x144/0x520
>> [c0000004a07abdd0] [c00000000002a864] timer_interrupt+0x104/0x2f0
>> [c0000004a07abe30] [c0000000000091c4] decrementer_common+0x114/0x120
>>
>> When perf record session started with "-I" option, capture registers
> ^
> is
>
>> via intr-regs,
>
> "intr-regs" is just the full name for the -I option, so that kind of
> repeats itself.
>
>> on each sample ‘is_sier_available()'i is called to check
> ^
> extra i
>
> The single quotes around is_sier_available() aren't necessary IMO.
>
>> for the SIER ( Sample Instruction Event Register) availability in the
> ^
> stray space
>> platform. This function in core-book3s access 'ppmu->flags'. If platform
> ^ ^
> es a
>> specific pmu driver is not registered, ppmu is set to null and accessing
> ^ ^
> PMU NULL
>> its members results in crash. Patch fixes this by returning false in
> ^
> a
>> 'is_sier_available()' if 'ppmu' is not set.
>
> Use the imperative mood for the last sentence which says what the patch
> does:
>
> Fix the crash by returning false in is_sier_available() if ppmu is not set.
Sure, I will make all these changes as suggested.
Thanks
Athira
>
>
>> Fixes: 333804dc3b7a ("powerpc/perf: Update perf_regs structure to include SIER")
>> Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
>> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/perf/core-book3s.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
>> index 08643cb..1de4770 100644
>> --- a/arch/powerpc/perf/core-book3s.c
>> +++ b/arch/powerpc/perf/core-book3s.c
>> @@ -137,6 +137,9 @@ static void pmao_restore_workaround(bool ebb) { }
>>
>> bool is_sier_available(void)
>> {
>> + if (!ppmu)
>> + return false;
>> +
>> if (ppmu->flags & PPMU_HAS_SIER)
>> return true;
>>
>> --
>> 1.8.3.1
>
>
> cheers
^ permalink raw reply
* Re: Linux kernel: powerpc: RTAS calls can be used to compromise kernel integrity
From: Andrew Donnellan @ 2020-11-23 14:41 UTC (permalink / raw)
To: oss-security, linuxppc-dev
In-Reply-To: <09cb1e1e-c71b-83a3-4c04-4e47e7c85342@linux.ibm.com>
On 9/10/20 12:20 pm, Andrew Donnellan wrote:
> The Linux kernel for powerpc has an issue with the Run-Time Abstraction
> Services (RTAS) interface, allowing root (or CAP_SYS_ADMIN users) in a
> VM to overwrite some parts of memory, including kernel memory.
>
> This issue impacts guests running on top of PowerVM or KVM hypervisors
> (pseries platform), and does *not* impact bare-metal machines (powernv
> platform).
CVE-2020-27777 has been assigned.
--
Andrew Donnellan OzLabs, ADL Canberra
ajd@linux.ibm.com IBM Australia Limited
^ permalink raw reply
* Re: [PATCH v2 04/19] powerpc/perf: move perf irq/nmi handling details into traps.c
From: Athira Rajeev @ 2020-11-23 17:54 UTC (permalink / raw)
To: Nicholas Piggin; +Cc: linuxppc-dev
In-Reply-To: <20201111094410.3038123-5-npiggin@gmail.com>
> On 11-Nov-2020, at 3:13 PM, Nicholas Piggin <npiggin@gmail.com> wrote:
>
> This is required in order to allow more significant differences between
> NMI type interrupt handlers and regular asynchronous handlers.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/kernel/traps.c | 31 +++++++++++++++++++++++++++-
> arch/powerpc/perf/core-book3s.c | 35 ++------------------------------
> arch/powerpc/perf/core-fsl-emb.c | 25 -----------------------
> 3 files changed, 32 insertions(+), 59 deletions(-)
>
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 902fcbd1a778..7dda72eb97cc 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -1919,11 +1919,40 @@ void vsx_unavailable_tm(struct pt_regs *regs)
> }
> #endif /* CONFIG_PPC_TRANSACTIONAL_MEM */
>
> -void performance_monitor_exception(struct pt_regs *regs)
> +static void performance_monitor_exception_nmi(struct pt_regs *regs)
> +{
> + nmi_enter();
> +
> + __this_cpu_inc(irq_stat.pmu_irqs);
> +
> + perf_irq(regs);
> +
> + nmi_exit();
> +}
> +
> +static void performance_monitor_exception_async(struct pt_regs *regs)
> {
> + irq_enter();
> +
> __this_cpu_inc(irq_stat.pmu_irqs);
>
> perf_irq(regs);
> +
> + irq_exit();
> +}
> +
> +void performance_monitor_exception(struct pt_regs *regs)
> +{
> + /*
> + * On 64-bit, if perf interrupts hit in a local_irq_disable
> + * (soft-masked) region, we consider them as NMIs. This is required to
> + * prevent hash faults on user addresses when reading callchains (and
> + * looks better from an irq tracing perspective).
> + */
> + if (IS_ENABLED(CONFIG_PPC64) && unlikely(arch_irq_disabled_regs(regs)))
> + performance_monitor_exception_nmi(regs);
> + else
> + performance_monitor_exception_async(regs);
> }
>
> #ifdef CONFIG_PPC_ADV_DEBUG_REGS
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index 08643cba1494..9fd8cae09218 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/perf/core-book3s.c
> @@ -109,10 +109,6 @@ static inline void perf_read_regs(struct pt_regs *regs)
> {
> regs->result = 0;
> }
> -static inline int perf_intr_is_nmi(struct pt_regs *regs)
> -{
> - return 0;
> -}
>
> static inline int siar_valid(struct pt_regs *regs)
> {
> @@ -328,15 +324,6 @@ static inline void perf_read_regs(struct pt_regs *regs)
> regs->result = use_siar;
> }
>
> -/*
> - * If interrupts were soft-disabled when a PMU interrupt occurs, treat
> - * it as an NMI.
> - */
> -static inline int perf_intr_is_nmi(struct pt_regs *regs)
> -{
> - return (regs->softe & IRQS_DISABLED);
> -}
> -
Hi Nick,
arch_irq_disabled_regs checks the regs->softe value, if it has IRQS_DISABLED set.
Core-book3s is also using same logic in perf_intr_is_nmi to check if it is an NMI. With the
changes in this patch, if I understood correctly, we will do the irq/nmi handling in traps.c
rather than doing it in the PMI interrupt handler. But can you please help to understand
better on what is the perf weirdness (sometimes NMI, sometimes not) mentioned in the cover
letter that we are fixing with this change ?
Thanks
Athira
> /*
> * On processors like P7+ that have the SIAR-Valid bit, marked instructions
> * must be sampled only if the SIAR-valid bit is set.
> @@ -2224,7 +2211,6 @@ static void __perf_event_interrupt(struct pt_regs *regs)
> struct perf_event *event;
> unsigned long val[8];
> int found, active;
> - int nmi;
>
> if (cpuhw->n_limited)
> freeze_limited_counters(cpuhw, mfspr(SPRN_PMC5),
> @@ -2232,18 +2218,6 @@ static void __perf_event_interrupt(struct pt_regs *regs)
>
> perf_read_regs(regs);
>
> - /*
> - * If perf interrupts hit in a local_irq_disable (soft-masked) region,
> - * we consider them as NMIs. This is required to prevent hash faults on
> - * user addresses when reading callchains. See the NMI test in
> - * do_hash_page.
> - */
> - nmi = perf_intr_is_nmi(regs);
> - if (nmi)
> - nmi_enter();
> - else
> - irq_enter();
> -
> /* Read all the PMCs since we'll need them a bunch of times */
> for (i = 0; i < ppmu->n_counter; ++i)
> val[i] = read_pmc(i + 1);
> @@ -2289,8 +2263,8 @@ static void __perf_event_interrupt(struct pt_regs *regs)
> }
> }
> }
> - if (!found && !nmi && printk_ratelimit())
> - printk(KERN_WARNING "Can't find PMC that caused IRQ\n");
> + if (unlikely(!found) && !arch_irq_disabled_regs(regs))
> + printk_ratelimited(KERN_WARNING "Can't find PMC that caused IRQ\n");
>
> /*
> * Reset MMCR0 to its normal value. This will set PMXE and
> @@ -2300,11 +2274,6 @@ static void __perf_event_interrupt(struct pt_regs *regs)
> * we get back out of this interrupt.
> */
> write_mmcr0(cpuhw, cpuhw->mmcr.mmcr0);
> -
> - if (nmi)
> - nmi_exit();
> - else
> - irq_exit();
> }
>
> static void perf_event_interrupt(struct pt_regs *regs)
> diff --git a/arch/powerpc/perf/core-fsl-emb.c b/arch/powerpc/perf/core-fsl-emb.c
> index e0e7e276bfd2..ee721f420a7b 100644
> --- a/arch/powerpc/perf/core-fsl-emb.c
> +++ b/arch/powerpc/perf/core-fsl-emb.c
> @@ -31,19 +31,6 @@ static atomic_t num_events;
> /* Used to avoid races in calling reserve/release_pmc_hardware */
> static DEFINE_MUTEX(pmc_reserve_mutex);
>
> -/*
> - * If interrupts were soft-disabled when a PMU interrupt occurs, treat
> - * it as an NMI.
> - */
> -static inline int perf_intr_is_nmi(struct pt_regs *regs)
> -{
> -#ifdef __powerpc64__
> - return (regs->softe & IRQS_DISABLED);
> -#else
> - return 0;
> -#endif
> -}
> -
> static void perf_event_interrupt(struct pt_regs *regs);
>
> /*
> @@ -659,13 +646,6 @@ static void perf_event_interrupt(struct pt_regs *regs)
> struct perf_event *event;
> unsigned long val;
> int found = 0;
> - int nmi;
> -
> - nmi = perf_intr_is_nmi(regs);
> - if (nmi)
> - nmi_enter();
> - else
> - irq_enter();
>
> for (i = 0; i < ppmu->n_counter; ++i) {
> event = cpuhw->event[i];
> @@ -690,11 +670,6 @@ static void perf_event_interrupt(struct pt_regs *regs)
> mtmsr(mfmsr() | MSR_PMM);
> mtpmr(PMRN_PMGC0, PMGC0_PMIE | PMGC0_FCECE);
> isync();
> -
> - if (nmi)
> - nmi_exit();
> - else
> - irq_exit();
> }
>
> void hw_perf_event_setup(int cpu)
> --
> 2.23.0
>
^ permalink raw reply
* Re: [PATCH v3 2/2] powerpc/ptrace: Hard wire PT_SOFTE value to 1 in gpr_get() too
From: Oleg Nesterov @ 2020-11-23 18:01 UTC (permalink / raw)
To: Christophe Leroy
Cc: Christophe Leroy, Madhavan Srinivasan, linuxppc-dev,
Nicholas Piggin, linux-kernel, Paul Mackerras, Al Viro,
Aneesh Kumar K.V, Jan Kratochvil
In-Reply-To: <20201119224347.GC5138@redhat.com>
Christophe, et al,
So what?
Are you going to push your change or should I re-send 1-2 without
whitespace cleanups?
On 11/19, Oleg Nesterov wrote:
>
> On 11/19, Christophe Leroy wrote:
> >
> > I think the following should work, and not require the first patch (compile
> > tested only).
> >
> > --- a/arch/powerpc/kernel/ptrace/ptrace-view.c
> > +++ b/arch/powerpc/kernel/ptrace/ptrace-view.c
> > @@ -234,9 +234,21 @@ static int gpr_get(struct task_struct *target, const
> > struct user_regset *regset,
> > BUILD_BUG_ON(offsetof(struct pt_regs, orig_gpr3) !=
> > offsetof(struct pt_regs, msr) + sizeof(long));
> >
> > +#ifdef CONFIG_PPC64
> > + membuf_write(&to, &target->thread.regs->orig_gpr3,
> > + offsetof(struct pt_regs, softe) - offsetof(struct pt_regs,
> > orig_gpr3));
> > + membuf_store(&to, 1UL);
> > +
> > + BUILD_BUG_ON(offsetof(struct pt_regs, trap) !=
> > + offsetof(struct pt_regs, softe) + sizeof(long));
> > +
> > + membuf_write(&to, &target->thread.regs->trap,
> > + sizeof(struct user_pt_regs) - offsetof(struct pt_regs, trap));
> > +#else
> > membuf_write(&to, &target->thread.regs->orig_gpr3,
> > sizeof(struct user_pt_regs) -
> > offsetof(struct pt_regs, orig_gpr3));
> > +#endif
> > return membuf_zero(&to, ELF_NGREG * sizeof(unsigned long) -
> > sizeof(struct user_pt_regs));
> > }
>
> Probably yes.
>
> This mirrors the previous patch I sent (https://lore.kernel.org/lkml/20190917143753.GA12300@redhat.com/)
> and this is exactly what I tried to avoid, we can make a simpler fix now.
>
> But let me repeat, I agree with any fix even if imp my version simplifies the code, just
> commit this change and lets forget this problem.
>
> Oleg.
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/64s: feature: Work around inline asm issues
From: Bill Wendling @ 2020-11-23 19:43 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Nick Desaulniers, linuxppc-dev
In-Reply-To: <20201123063432.GG2672@gate.crashing.org>
What Segher said. :-) Also, if you reverse the comparison, you'll get
a build error.
On Sun, Nov 22, 2020 at 10:36 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> On Mon, Nov 23, 2020 at 04:44:56PM +1100, Michael Ellerman wrote:
> > If I hard code:
> >
> > .org . - (1);
> >
> > It fails as expected.
> >
> > But if I hard code:
> >
> > .org . - (1 > 0);
> >
> > It builds?
>
> "true" (as a result of a comparison) in as is -1, not 1.
>
>
> Segher
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/64s: feature: Work around inline asm issues
From: Bill Wendling @ 2020-11-23 19:53 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Nick Desaulniers, linuxppc-dev
In-Reply-To: <CAGG=3QVjSAwU+ebvH=Lk5YVMxW7=ThvkJXGPw+95nYxxuurMig@mail.gmail.com>
After looking at this, I suspect that the correct change should be:
.org . + ((label##4b-label##3b) > (label##2b-label##1b));
I'm sorry about that. I can submit another version of the patch.
-bw
On Mon, Nov 23, 2020 at 11:43 AM Bill Wendling <morbo@google.com> wrote:
>
> What Segher said. :-) Also, if you reverse the comparison, you'll get
> a build error.
>
> On Sun, Nov 22, 2020 at 10:36 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> >
> > On Mon, Nov 23, 2020 at 04:44:56PM +1100, Michael Ellerman wrote:
> > > If I hard code:
> > >
> > > .org . - (1);
> > >
> > > It fails as expected.
> > >
> > > But if I hard code:
> > >
> > > .org . - (1 > 0);
> > >
> > > It builds?
> >
> > "true" (as a result of a comparison) in as is -1, not 1.
> >
> >
> > Segher
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/64s: feature: Work around inline asm issues
From: Segher Boessenkool @ 2020-11-23 19:56 UTC (permalink / raw)
To: Bill Wendling; +Cc: Nick Desaulniers, linuxppc-dev
In-Reply-To: <CAGG=3QVjSAwU+ebvH=Lk5YVMxW7=ThvkJXGPw+95nYxxuurMig@mail.gmail.com>
(Please don't top-post.)
> On Sun, Nov 22, 2020 at 10:36 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > "true" (as a result of a comparison) in as is -1, not 1.
On Mon, Nov 23, 2020 at 11:43:11AM -0800, Bill Wendling wrote:
> What Segher said. :-) Also, if you reverse the comparison, you'll get
> a build error.
But that means your patch is the wrong way around?
- .ifgt (label##4b- label##3b)-(label##2b- label##1b); \
- .error "Feature section else case larger than body"; \
- .endif; \
+ .org . - ((label##4b-label##3b) > (label##2b-label##1b)); \
It should be a + in that last line, not a -. Was this tested?
Segher
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/64s: feature: Work around inline asm issues
From: Bill Wendling @ 2020-11-23 20:01 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Nick Desaulniers, linuxppc-dev
In-Reply-To: <20201123195622.GI2672@gate.crashing.org>
On Mon, Nov 23, 2020 at 11:58 AM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> > On Sun, Nov 22, 2020 at 10:36 PM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> > > "true" (as a result of a comparison) in as is -1, not 1.
>
> On Mon, Nov 23, 2020 at 11:43:11AM -0800, Bill Wendling wrote:
> > What Segher said. :-) Also, if you reverse the comparison, you'll get
> > a build error.
>
> But that means your patch is the wrong way around?
>
> - .ifgt (label##4b- label##3b)-(label##2b- label##1b); \
> - .error "Feature section else case larger than body"; \
> - .endif; \
> + .org . - ((label##4b-label##3b) > (label##2b-label##1b)); \
>
> It should be a + in that last line, not a -.
I said so in a follow up email.
> Was this tested?
>
Please don't be insulting. Anyone can make an error.
-bw
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/64s: feature: Work around inline asm issues
From: Segher Boessenkool @ 2020-11-23 20:08 UTC (permalink / raw)
To: Bill Wendling; +Cc: Nick Desaulniers, linuxppc-dev
In-Reply-To: <CAGG=3QXR=Yfh8PNa4m-kQLTBP4YKD8OGm_6fSUgeasQ1ar9b2g@mail.gmail.com>
On Mon, Nov 23, 2020 at 12:01:01PM -0800, Bill Wendling wrote:
> On Mon, Nov 23, 2020 at 11:58 AM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > > On Sun, Nov 22, 2020 at 10:36 PM Segher Boessenkool
> > > <segher@kernel.crashing.org> wrote:
> > > > "true" (as a result of a comparison) in as is -1, not 1.
> >
> > On Mon, Nov 23, 2020 at 11:43:11AM -0800, Bill Wendling wrote:
> > > What Segher said. :-) Also, if you reverse the comparison, you'll get
> > > a build error.
> >
> > But that means your patch is the wrong way around?
> >
> > - .ifgt (label##4b- label##3b)-(label##2b- label##1b); \
> > - .error "Feature section else case larger than body"; \
> > - .endif; \
> > + .org . - ((label##4b-label##3b) > (label##2b-label##1b)); \
> >
> > It should be a + in that last line, not a -.
>
> I said so in a follow up email.
Yeah, and that arrived a second after I pressed "send" :-)
> > Was this tested?
> >
> Please don't be insulting. Anyone can make an error.
Absolutely, but it is just a question. It seems you could improve that
testing! It helps you yourself most of all ;-)
Segher
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/64s: feature: Work around inline asm issues
From: Bill Wendling @ 2020-11-23 20:17 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Nick Desaulniers, linuxppc-dev
In-Reply-To: <20201123200846.GJ2672@gate.crashing.org>
On Mon, Nov 23, 2020 at 12:10 PM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> On Mon, Nov 23, 2020 at 12:01:01PM -0800, Bill Wendling wrote:
> > On Mon, Nov 23, 2020 at 11:58 AM Segher Boessenkool
> > <segher@kernel.crashing.org> wrote:
> > > > On Sun, Nov 22, 2020 at 10:36 PM Segher Boessenkool
> > > > <segher@kernel.crashing.org> wrote:
> > > > > "true" (as a result of a comparison) in as is -1, not 1.
> > >
> > > On Mon, Nov 23, 2020 at 11:43:11AM -0800, Bill Wendling wrote:
> > > > What Segher said. :-) Also, if you reverse the comparison, you'll get
> > > > a build error.
> > >
> > > But that means your patch is the wrong way around?
> > >
> > > - .ifgt (label##4b- label##3b)-(label##2b- label##1b); \
> > > - .error "Feature section else case larger than body"; \
> > > - .endif; \
> > > + .org . - ((label##4b-label##3b) > (label##2b-label##1b)); \
> > >
> > > It should be a + in that last line, not a -.
> >
> > I said so in a follow up email.
>
> Yeah, and that arrived a second after I pressed "send" :-)
>
Michael, I apologize for the churn with these patches. I believe the
policy is to resend the match as "v4", correct?
I ran tests with the change above. It compiled with no error. If I
switch the labels around to ".org . + ((label##2b-label##1b) >
(label##4b-label##3b))", then it fails as expected.
-bw
^ permalink raw reply
* Re: linux-next: build failure in Linus' tree
From: Michael Ellerman @ 2020-11-23 23:39 UTC (permalink / raw)
To: Michael Ellerman, Stephen Rothwell, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Nicholas Piggin, Daniel Axtens
In-Reply-To: <20201123184016.693fe464@canb.auug.org.au>
On Mon, 23 Nov 2020 18:40:16 +1100, Stephen Rothwell wrote:
> After merging most of the trees, today's linux-next build (powerpc64
> allnoconfig) failed like this:
>
> In file included from arch/powerpc/include/asm/kup.h:18,
> from arch/powerpc/include/asm/uaccess.h:9,
> from include/linux/uaccess.h:11,
> from include/linux/sched/task.h:11,
> from include/linux/sched/signal.h:9,
> from include/linux/rcuwait.h:6,
> from include/linux/percpu-rwsem.h:7,
> from include/linux/fs.h:33,
> from include/linux/compat.h:17,
> from arch/powerpc/kernel/asm-offsets.c:14:
> arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: warning: data definition has no type or storage class
> 66 | DECLARE_STATIC_KEY_FALSE(uaccess_flush_key);
> | ^~~~~~~~~~~~~~~~~~~~~~~~
> arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: error: type defaults to 'int' in declaration of 'DECLARE_STATIC_KEY_FALSE' [-Werror=implicit-int]
> arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: warning: parameter names (without types) in function declaration
> arch/powerpc/include/asm/book3s/64/kup-radix.h: In function 'prevent_user_access':
> arch/powerpc/include/asm/book3s/64/kup-radix.h:180:6: error: implicit declaration of function 'static_branch_unlikely' [-Werror=implicit-function-declaration]
> 180 | if (static_branch_unlikely(&uaccess_flush_key))
> | ^~~~~~~~~~~~~~~~~~~~~~
> arch/powerpc/include/asm/book3s/64/kup-radix.h:180:30: error: 'uaccess_flush_key' undeclared (first use in this function)
> 180 | if (static_branch_unlikely(&uaccess_flush_key))
> | ^~~~~~~~~~~~~~~~~
> arch/powerpc/include/asm/book3s/64/kup-radix.h:180:30: note: each undeclared identifier is reported only once for each function it appears in
> arch/powerpc/include/asm/book3s/64/kup-radix.h: In function 'prevent_user_access_return':
> arch/powerpc/include/asm/book3s/64/kup-radix.h:189:30: error: 'uaccess_flush_key' undeclared (first use in this function)
> 189 | if (static_branch_unlikely(&uaccess_flush_key))
> | ^~~~~~~~~~~~~~~~~
> arch/powerpc/include/asm/book3s/64/kup-radix.h: In function 'restore_user_access':
> arch/powerpc/include/asm/book3s/64/kup-radix.h:198:30: error: 'uaccess_flush_key' undeclared (first use in this function)
> 198 | if (static_branch_unlikely(&uaccess_flush_key) && flags == AMR_KUAP_BLOCKED)
> | ^~~~~~~~~~~~~~~~~
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/64s: Fix allnoconfig build since uaccess flush
https://git.kernel.org/powerpc/c/b6b79dd53082db11070b4368d85dd6699ff0b063
cheers
^ permalink raw reply
* Re: linux-next: build failure in Linus' tree
From: Daniel Axtens @ 2020-11-24 0:23 UTC (permalink / raw)
To: Michael Ellerman, Michael Ellerman, Stephen Rothwell, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Nicholas Piggin
In-Reply-To: <160617472873.1817800.16473753588453276266.b4-ty@ellerman.id.au>
Thanks sfr and mpe.
> Applied to powerpc/fixes.
>
> [1/1] powerpc/64s: Fix allnoconfig build since uaccess flush
> https://git.kernel.org/powerpc/c/b6b79dd53082db11070b4368d85dd6699ff0b063
We also needed a similar fix for stable, which has also been applied.
I guess I should build some sort of build process that tests a whole
range of configs. I did test a few but clearly not enough. Is there a
known list that I should be using? Something from kisskb?
Kind regards,
Daniel
Michael Ellerman <patch-notifications@ellerman.id.au> writes:
> On Mon, 23 Nov 2020 18:40:16 +1100, Stephen Rothwell wrote:
>> After merging most of the trees, today's linux-next build (powerpc64
>> allnoconfig) failed like this:
>>
>> In file included from arch/powerpc/include/asm/kup.h:18,
>> from arch/powerpc/include/asm/uaccess.h:9,
>> from include/linux/uaccess.h:11,
>> from include/linux/sched/task.h:11,
>> from include/linux/sched/signal.h:9,
>> from include/linux/rcuwait.h:6,
>> from include/linux/percpu-rwsem.h:7,
>> from include/linux/fs.h:33,
>> from include/linux/compat.h:17,
>> from arch/powerpc/kernel/asm-offsets.c:14:
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: warning: data definition has no type or storage class
>> 66 | DECLARE_STATIC_KEY_FALSE(uaccess_flush_key);
>> | ^~~~~~~~~~~~~~~~~~~~~~~~
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: error: type defaults to 'int' in declaration of 'DECLARE_STATIC_KEY_FALSE' [-Werror=implicit-int]
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:66:1: warning: parameter names (without types) in function declaration
>> arch/powerpc/include/asm/book3s/64/kup-radix.h: In function 'prevent_user_access':
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:180:6: error: implicit declaration of function 'static_branch_unlikely' [-Werror=implicit-function-declaration]
>> 180 | if (static_branch_unlikely(&uaccess_flush_key))
>> | ^~~~~~~~~~~~~~~~~~~~~~
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:180:30: error: 'uaccess_flush_key' undeclared (first use in this function)
>> 180 | if (static_branch_unlikely(&uaccess_flush_key))
>> | ^~~~~~~~~~~~~~~~~
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:180:30: note: each undeclared identifier is reported only once for each function it appears in
>> arch/powerpc/include/asm/book3s/64/kup-radix.h: In function 'prevent_user_access_return':
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:189:30: error: 'uaccess_flush_key' undeclared (first use in this function)
>> 189 | if (static_branch_unlikely(&uaccess_flush_key))
>> | ^~~~~~~~~~~~~~~~~
>> arch/powerpc/include/asm/book3s/64/kup-radix.h: In function 'restore_user_access':
>> arch/powerpc/include/asm/book3s/64/kup-radix.h:198:30: error: 'uaccess_flush_key' undeclared (first use in this function)
>> 198 | if (static_branch_unlikely(&uaccess_flush_key) && flags == AMR_KUAP_BLOCKED)
>> | ^~~~~~~~~~~~~~~~~
>>
>> [...]
>
^ permalink raw reply
* Re: [PATCH 00/25] Rid W=1 warnings in SoC
From: Li Yang @ 2020-11-24 0:44 UTC (permalink / raw)
To: Lee Jones
Cc: Heiko Stuebner, Roy Pledge, Liam Girdwood, Scott Wood,
Thierry Reding, Qiang Zhao, linux-samsung-soc, Rafael J. Wysocki,
YueHaibing, Sandeep Nair, Krzysztof Kozlowski, Jonathan Hunter,
linux-rockchip, act, Andy Gross, bcm-kernel-feedback-list,
Cyril Chemparathy, linux-arm-msm, Florian Fainelli,
Santosh Shilimkar, linux-tegra, Bjorn Andersson,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Software, Inc, Dave Gerlach, Doug Anderson, lkml, Ben Dooks,
Mark Brown, Dan Malek, Vitaly Bordug, linuxppc-dev
In-Reply-To: <20201103152838.1290217-1-lee.jones@linaro.org>
On Tue, Nov 3, 2020 at 9:29 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> This set is part of a larger effort attempting to clean-up W=1
> kernel builds, which are currently overwhelmingly riddled with
> niggly little warnings.
>
> Lee Jones (25):
> soc: fsl: dpio: qbman-portal: Fix a bunch of kernel-doc misdemeanours
> soc: fsl: qe: qe_common: Fix misnamed function attribute 'addr'
> soc: fsl: qbman: qman: Remove unused variable 'dequeue_wq'
The above are applied for next. Thanks.
Regards,
Leo
>
> drivers/soc/bcm/brcmstb/pm/pm-arm.c | 2 +
> drivers/soc/fsl/dpio/qbman-portal.c | 18 +++++--
> drivers/soc/fsl/qbman/qman.c | 8 +--
> drivers/soc/fsl/qe/qe_common.c | 2 +-
> drivers/soc/qcom/kryo-l2-accessors.c | 2 +-
> drivers/soc/qcom/llcc-qcom.c | 2 +-
> drivers/soc/qcom/qcom-geni-se.c | 5 +-
> drivers/soc/qcom/qcom_aoss.c | 4 +-
> drivers/soc/qcom/rpmh.c | 2 +-
> drivers/soc/qcom/rpmhpd.c | 3 ++
> drivers/soc/qcom/smem.c | 3 +-
> drivers/soc/qcom/smp2p.c | 3 +-
> drivers/soc/qcom/smsm.c | 4 +-
> drivers/soc/qcom/wcnss_ctrl.c | 8 +--
> drivers/soc/rockchip/io-domain.c | 3 --
> drivers/soc/samsung/s3c-pm-check.c | 2 +-
> drivers/soc/tegra/fuse/speedo-tegra124.c | 7 ++-
> drivers/soc/tegra/fuse/speedo-tegra210.c | 8 +--
> drivers/soc/ti/k3-ringacc.c | 1 +
> drivers/soc/ti/knav_dma.c | 2 +-
> drivers/soc/ti/knav_qmss_queue.c | 62 ++++++++++++------------
> drivers/soc/ti/pm33xx.c | 4 +-
> drivers/soc/ti/wkup_m3_ipc.c | 8 ++-
> 23 files changed, 86 insertions(+), 77 deletions(-)
>
> Cc: act <dmalek@jlc.net>
> Cc: Andy Gross <agross@kernel.org>
> Cc: bcm-kernel-feedback-list@broadcom.com
> Cc: Ben Dooks <ben@simtec.co.uk>
> Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
> Cc: Cyril Chemparathy <cyril@ti.com>
> Cc: Dan Malek <dan@embeddedalley.com>
> Cc: Dave Gerlach <d-gerlach@ti.com>
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Jonathan Hunter <jonathanh@nvidia.com>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: linux-arm-msm@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-rockchip@lists.infradead.org
> Cc: linux-samsung-soc@vger.kernel.org
> Cc: linux-tegra@vger.kernel.org
> Cc: Li Yang <leoyang.li@nxp.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Qiang Zhao <qiang.zhao@nxp.com>
> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
> Cc: Roy Pledge <Roy.Pledge@nxp.com>
> Cc: Sandeep Nair <sandeep_n@ti.com>
> Cc: Santosh Shilimkar <ssantosh@kernel.org>
> Cc: Scott Wood <scottwood@freescale.com>
> Cc: "Software, Inc" <source@mvista.com>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Vitaly Bordug <vbordug@ru.mvista.com>
> Cc: YueHaibing <yuehaibing@huawei.com>
>
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH 25/25] soc: fsl: qbman: qman: Remove unused variable 'dequeue_wq'
From: Li Yang @ 2020-11-24 0:49 UTC (permalink / raw)
To: Roy Pledge
Cc: linuxppc-dev, Lee Jones, YueHaibing, lkml,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20201103152838.1290217-26-lee.jones@linaro.org>
Hi Roy,
On Tue, Nov 3, 2020 at 9:31 AM Lee Jones <lee.jones@linaro.org> wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/soc/fsl/qbman/qman.c: In function ‘qman_shutdown_fq’:
> drivers/soc/fsl/qbman/qman.c:2700:8: warning: variable ‘dequeue_wq’ set but not used [-Wunused-but-set-variable]
>
> Cc: Li Yang <leoyang.li@nxp.com>
> Cc: YueHaibing <yuehaibing@huawei.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> drivers/soc/fsl/qbman/qman.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
> index 9888a70618730..62b182c3a8b04 100644
> --- a/drivers/soc/fsl/qbman/qman.c
> +++ b/drivers/soc/fsl/qbman/qman.c
> @@ -2622,7 +2622,7 @@ int qman_shutdown_fq(u32 fqid)
> union qm_mc_command *mcc;
> union qm_mc_result *mcr;
> int orl_empty, drain = 0, ret = 0;
> - u32 channel, wq, res;
> + u32 channel, res;
> u8 state;
>
> p = get_affine_portal();
> @@ -2655,7 +2655,7 @@ int qman_shutdown_fq(u32 fqid)
> DPAA_ASSERT((mcr->verb & QM_MCR_VERB_MASK) == QM_MCR_VERB_QUERYFQ);
> /* Need to store these since the MCR gets reused */
> channel = qm_fqd_get_chan(&mcr->queryfq.fqd);
> - wq = qm_fqd_get_wq(&mcr->queryfq.fqd);
> + qm_fqd_get_wq(&mcr->queryfq.fqd);
This probably is not needed also.
>
> if (channel < qm_channel_pool1) {
> channel_portal = get_portal_for_channel(channel);
> @@ -2697,7 +2697,6 @@ int qman_shutdown_fq(u32 fqid)
> * to dequeue from the channel the FQ is scheduled on
> */
> int found_fqrn = 0;
> - u16 dequeue_wq = 0;
>
> /* Flag that we need to drain FQ */
> drain = 1;
> @@ -2705,11 +2704,8 @@ int qman_shutdown_fq(u32 fqid)
> if (channel >= qm_channel_pool1 &&
> channel < qm_channel_pool1 + 15) {
> /* Pool channel, enable the bit in the portal */
> - dequeue_wq = (channel -
> - qm_channel_pool1 + 1)<<4 | wq;
> } else if (channel < qm_channel_pool1) {
> /* Dedicated channel */
> - dequeue_wq = wq;
With these gone, these if statements seem to be redundant. Can you
propose an additional patch to further cleanup the code here? Thanks.
> } else {
> dev_err(dev, "Can't recover FQ 0x%x, ch: 0x%x",
> fqid, channel);
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH v3 2/2] powerpc/ptrace: Hard wire PT_SOFTE value to 1 in gpr_get() too
From: Michael Ellerman @ 2020-11-24 0:53 UTC (permalink / raw)
To: Oleg Nesterov, Christophe Leroy
Cc: Christophe Leroy, Madhavan Srinivasan, linuxppc-dev,
Nicholas Piggin, linux-kernel, Paul Mackerras, Al Viro,
Aneesh Kumar K.V, Jan Kratochvil
In-Reply-To: <20201123180142.GB20279@redhat.com>
Oleg Nesterov <oleg@redhat.com> writes:
> Christophe, et al,
>
> So what?
>
> Are you going to push your change or should I re-send 1-2 without
> whitespace cleanups?
I'll take your 1 & 2 and fixup the whitespace issues when applying.
cheers
> On 11/19, Oleg Nesterov wrote:
>>
>> On 11/19, Christophe Leroy wrote:
>> >
>> > I think the following should work, and not require the first patch (compile
>> > tested only).
>> >
>> > --- a/arch/powerpc/kernel/ptrace/ptrace-view.c
>> > +++ b/arch/powerpc/kernel/ptrace/ptrace-view.c
>> > @@ -234,9 +234,21 @@ static int gpr_get(struct task_struct *target, const
>> > struct user_regset *regset,
>> > BUILD_BUG_ON(offsetof(struct pt_regs, orig_gpr3) !=
>> > offsetof(struct pt_regs, msr) + sizeof(long));
>> >
>> > +#ifdef CONFIG_PPC64
>> > + membuf_write(&to, &target->thread.regs->orig_gpr3,
>> > + offsetof(struct pt_regs, softe) - offsetof(struct pt_regs,
>> > orig_gpr3));
>> > + membuf_store(&to, 1UL);
>> > +
>> > + BUILD_BUG_ON(offsetof(struct pt_regs, trap) !=
>> > + offsetof(struct pt_regs, softe) + sizeof(long));
>> > +
>> > + membuf_write(&to, &target->thread.regs->trap,
>> > + sizeof(struct user_pt_regs) - offsetof(struct pt_regs, trap));
>> > +#else
>> > membuf_write(&to, &target->thread.regs->orig_gpr3,
>> > sizeof(struct user_pt_regs) -
>> > offsetof(struct pt_regs, orig_gpr3));
>> > +#endif
>> > return membuf_zero(&to, ELF_NGREG * sizeof(unsigned long) -
>> > sizeof(struct user_pt_regs));
>> > }
>>
>> Probably yes.
>>
>> This mirrors the previous patch I sent (https://lore.kernel.org/lkml/20190917143753.GA12300@redhat.com/)
>> and this is exactly what I tried to avoid, we can make a simpler fix now.
>>
>> But let me repeat, I agree with any fix even if imp my version simplifies the code, just
>> commit this change and lets forget this problem.
>>
>> Oleg.
^ permalink raw reply
* Re: [PATCH v3] soc: fsl: dpio: Get the cpumask through cpumask_of(cpu)
From: Li Yang @ 2020-11-24 1:25 UTC (permalink / raw)
To: Yi Wang
Cc: jiang.xuexin, Hao Si, Roy Pledge, lkml, Lin Chen, xue.zhihong,
linuxppc-dev,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <20201020021832.36846-1-wang.yi59@zte.com.cn>
On Mon, Oct 19, 2020 at 9:15 PM Yi Wang <wang.yi59@zte.com.cn> wrote:
>
> From: Hao Si <si.hao@zte.com.cn>
>
> The local variable 'cpumask_t mask' is in the stack memory, and its address
> is assigned to 'desc->affinity' in 'irq_set_affinity_hint()'.
> But the memory area where this variable is located is at risk of being
> modified.
>
> During LTP testing, the following error was generated:
>
> Unable to handle kernel paging request at virtual address ffff000012e9b790
> Mem abort info:
> ESR = 0x96000007
> Exception class = DABT (current EL), IL = 32 bits
> SET = 0, FnV = 0
> EA = 0, S1PTW = 0
> Data abort info:
> ISV = 0, ISS = 0x00000007
> CM = 0, WnR = 0
> swapper pgtable: 4k pages, 48-bit VAs, pgdp = 0000000075ac5e07
> [ffff000012e9b790] pgd=00000027dbffe003, pud=00000027dbffd003,
> pmd=00000027b6d61003, pte=0000000000000000
> Internal error: Oops: 96000007 [#1] PREEMPT SMP
> Modules linked in: xt_conntrack
> Process read_all (pid: 20171, stack limit = 0x0000000044ea4095)
> CPU: 14 PID: 20171 Comm: read_all Tainted: G B W
> Hardware name: NXP Layerscape LX2160ARDB (DT)
> pstate: 80000085 (Nzcv daIf -PAN -UAO)
> pc : irq_affinity_hint_proc_show+0x54/0xb0
> lr : irq_affinity_hint_proc_show+0x4c/0xb0
> sp : ffff00001138bc10
> x29: ffff00001138bc10 x28: 0000ffffd131d1e0
> x27: 00000000007000c0 x26: ffff8025b9480dc0
> x25: ffff8025b9480da8 x24: 00000000000003ff
> x23: ffff8027334f8300 x22: ffff80272e97d000
> x21: ffff80272e97d0b0 x20: ffff8025b9480d80
> x19: ffff000009a49000 x18: 0000000000000000
> x17: 0000000000000000 x16: 0000000000000000
> x15: 0000000000000000 x14: 0000000000000000
> x13: 0000000000000000 x12: 0000000000000040
> x11: 0000000000000000 x10: ffff802735b79b88
> x9 : 0000000000000000 x8 : 0000000000000000
> x7 : ffff000009a49848 x6 : 0000000000000003
> x5 : 0000000000000000 x4 : ffff000008157d6c
> x3 : ffff00001138bc10 x2 : ffff000012e9b790
> x1 : 0000000000000000 x0 : 0000000000000000
> Call trace:
> irq_affinity_hint_proc_show+0x54/0xb0
> seq_read+0x1b0/0x440
> proc_reg_read+0x80/0xd8
> __vfs_read+0x60/0x178
> vfs_read+0x94/0x150
> ksys_read+0x74/0xf0
> __arm64_sys_read+0x24/0x30
> el0_svc_common.constprop.0+0xd8/0x1a0
> el0_svc_handler+0x34/0x88
> el0_svc+0x10/0x14
> Code: f9001bbf 943e0732 f94066c2 b4000062 (f9400041)
> ---[ end trace b495bdcb0b3b732b ]---
> Kernel panic - not syncing: Fatal exception
> SMP: stopping secondary CPUs
> SMP: failed to stop secondary CPUs 0,2-4,6,8,11,13-15
> Kernel Offset: disabled
> CPU features: 0x0,21006008
> Memory Limit: none
> ---[ end Kernel panic - not syncing: Fatal exception ]---
>
> Fix it by using 'cpumask_of(cpu)' to get the cpumask.
>
> Signed-off-by: Hao Si <si.hao@zte.com.cn>
> Signed-off-by: Lin Chen <chen.lin5@zte.com.cn>
> Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
Applied for fix. Thanks.
> ---
> v3: Use cpumask_of(cpu) to get the pre-defined cpumask in the static
> cpu_bit_bitmap array.
> v2: Place 'cpumask_t mask' in the driver's private data and while at it,
> rename it to cpu_mask.
>
> drivers/soc/fsl/dpio/dpio-driver.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/soc/fsl/dpio/dpio-driver.c b/drivers/soc/fsl/dpio/dpio-driver.c
> index 7b642c3..7f397b4 100644
> --- a/drivers/soc/fsl/dpio/dpio-driver.c
> +++ b/drivers/soc/fsl/dpio/dpio-driver.c
> @@ -95,7 +95,6 @@ static int register_dpio_irq_handlers(struct fsl_mc_device *dpio_dev, int cpu)
> {
> int error;
> struct fsl_mc_device_irq *irq;
> - cpumask_t mask;
>
> irq = dpio_dev->irqs[0];
> error = devm_request_irq(&dpio_dev->dev,
> @@ -112,9 +111,7 @@ static int register_dpio_irq_handlers(struct fsl_mc_device *dpio_dev, int cpu)
> }
>
> /* set the affinity hint */
> - cpumask_clear(&mask);
> - cpumask_set_cpu(cpu, &mask);
> - if (irq_set_affinity_hint(irq->msi_desc->irq, &mask))
> + if (irq_set_affinity_hint(irq->msi_desc->irq, cpumask_of(cpu)))
> dev_err(&dpio_dev->dev,
> "irq_set_affinity failed irq %d cpu %d\n",
> irq->msi_desc->irq, cpu);
> --
> 2.15.2
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS 7c94b5d4e9d328a69d43a11d7e3dfd7a6d762cb6
From: kernel test robot @ 2020-11-24 2:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: 7c94b5d4e9d328a69d43a11d7e3dfd7a6d762cb6 Automatic merge of 'fixes' into merge (2020-11-23 23:32)
elapsed time: 789m
configs tested: 145
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arm zeus_defconfig
powerpc bluestone_defconfig
sh apsh4a3a_defconfig
arm mvebu_v7_defconfig
sh magicpanelr2_defconfig
arm nhk8815_defconfig
xtensa generic_kc705_defconfig
arm tct_hammer_defconfig
arm vexpress_defconfig
powerpc canyonlands_defconfig
powerpc kilauea_defconfig
mips sb1250_swarm_defconfig
xtensa virt_defconfig
sh r7780mp_defconfig
arm netwinder_defconfig
xtensa defconfig
arm u300_defconfig
powerpc xes_mpc85xx_defconfig
powerpc mpc832x_rdb_defconfig
arm pleb_defconfig
mips allyesconfig
arm keystone_defconfig
mips ip32_defconfig
sh se7724_defconfig
csky alldefconfig
arm dove_defconfig
m68k sun3_defconfig
sh rts7751r2dplus_defconfig
sh rsk7203_defconfig
arm gemini_defconfig
arm s5pv210_defconfig
sparc64 alldefconfig
powerpc akebono_defconfig
arm s3c6400_defconfig
sparc alldefconfig
sh se7721_defconfig
mips gcw0_defconfig
mips fuloong2e_defconfig
powerpc lite5200b_defconfig
mips ath79_defconfig
nds32 alldefconfig
arm cm_x300_defconfig
arm shmobile_defconfig
mips jmr3927_defconfig
ia64 gensparse_defconfig
arm hackkit_defconfig
mips ar7_defconfig
arm realview_defconfig
arm footbridge_defconfig
arm mainstone_defconfig
arm assabet_defconfig
arm colibri_pxa270_defconfig
arm davinci_all_defconfig
sh se7750_defconfig
arc haps_hs_smp_defconfig
mips mtx1_defconfig
arc defconfig
sh urquell_defconfig
sh sdk7780_defconfig
alpha defconfig
sh ecovec24_defconfig
powerpc arches_defconfig
powerpc currituck_defconfig
arm pxa168_defconfig
mips vocore2_defconfig
powerpc pq2fads_defconfig
powerpc socrates_defconfig
mips db1xxx_defconfig
arc alldefconfig
xtensa audio_kc705_defconfig
mips rbtx49xx_defconfig
arm mps2_defconfig
c6x evmc6474_defconfig
arm spear3xx_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
s390 defconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
i386 randconfig-a004-20201123
i386 randconfig-a003-20201123
i386 randconfig-a002-20201123
i386 randconfig-a005-20201123
i386 randconfig-a001-20201123
i386 randconfig-a006-20201123
x86_64 randconfig-a015-20201123
x86_64 randconfig-a011-20201123
x86_64 randconfig-a014-20201123
x86_64 randconfig-a016-20201123
x86_64 randconfig-a012-20201123
x86_64 randconfig-a013-20201123
i386 randconfig-a012-20201123
i386 randconfig-a013-20201123
i386 randconfig-a011-20201123
i386 randconfig-a016-20201123
i386 randconfig-a014-20201123
i386 randconfig-a015-20201123
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20201123
x86_64 randconfig-a003-20201123
x86_64 randconfig-a004-20201123
x86_64 randconfig-a005-20201123
x86_64 randconfig-a002-20201123
x86_64 randconfig-a001-20201123
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [powerpc:next-test] BUILD SUCCESS c250581fcf84c34cbaf5b535512b60a5e96970f6
From: kernel test robot @ 2020-11-24 2:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test
branch HEAD: c250581fcf84c34cbaf5b535512b60a5e96970f6 powerpc/vdso: Provide __kernel_clock_gettime64() on vdso32
elapsed time: 5500m
configs tested: 212
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
arc haps_hs_smp_defconfig
mips db1xxx_defconfig
mips malta_kvm_defconfig
m68k sun3x_defconfig
s390 defconfig
mips cavium_octeon_defconfig
powerpc ge_imp3a_defconfig
powerpc xes_mpc85xx_defconfig
sh sdk7786_defconfig
arm pxa168_defconfig
arm zeus_defconfig
powerpc bluestone_defconfig
sh apsh4a3a_defconfig
arm mvebu_v7_defconfig
sh magicpanelr2_defconfig
arm nhk8815_defconfig
xtensa generic_kc705_defconfig
arm tct_hammer_defconfig
arm vexpress_defconfig
powerpc canyonlands_defconfig
powerpc kilauea_defconfig
mips sb1250_swarm_defconfig
arc nsimosci_hs_smp_defconfig
arm u8500_defconfig
powerpc tqm8555_defconfig
c6x evmc6472_defconfig
arm hackkit_defconfig
sh sh7724_generic_defconfig
powerpc obs600_defconfig
powerpc mpc512x_defconfig
arm h3600_defconfig
arm cerfcube_defconfig
sh sh7757lcr_defconfig
sh rsk7201_defconfig
arm alldefconfig
mips allyesconfig
arm keystone_defconfig
mips ip32_defconfig
arm u300_defconfig
arm palmz72_defconfig
mips ath25_defconfig
powerpc tqm8xx_defconfig
m68k mvme16x_defconfig
powerpc storcenter_defconfig
powerpc acadia_defconfig
mips vocore2_defconfig
sh rsk7269_defconfig
parisc alldefconfig
mips pic32mzda_defconfig
arm xcep_defconfig
sh se7343_defconfig
sh dreamcast_defconfig
sh se7724_defconfig
csky alldefconfig
arm dove_defconfig
m68k sun3_defconfig
sh rts7751r2dplus_defconfig
sh rsk7203_defconfig
arm gemini_defconfig
arm s5pv210_defconfig
sparc64 alldefconfig
arm aspeed_g4_defconfig
arm shmobile_defconfig
c6x defconfig
arc alldefconfig
arm ep93xx_defconfig
alpha defconfig
ia64 zx1_defconfig
ia64 gensparse_defconfig
sh hp6xx_defconfig
mips ip27_defconfig
powerpc mvme5100_defconfig
arm colibri_pxa270_defconfig
nds32 allnoconfig
powerpc allnoconfig
mips jmr3927_defconfig
xtensa iss_defconfig
nds32 alldefconfig
arm cm_x300_defconfig
arm davinci_all_defconfig
powerpc mpc8540_ads_defconfig
powerpc arches_defconfig
mips maltaup_defconfig
powerpc tqm8540_defconfig
powerpc akebono_defconfig
arm realview_defconfig
arm footbridge_defconfig
sh se7721_defconfig
powerpc powernv_defconfig
sh se7751_defconfig
mips loongson1b_defconfig
arm tango4_defconfig
xtensa nommu_kc705_defconfig
arm moxart_defconfig
sh sdk7780_defconfig
riscv rv32_defconfig
mips decstation_defconfig
arm mvebu_v5_defconfig
powerpc pcm030_defconfig
arm magician_defconfig
um kunit_defconfig
powerpc ppa8548_defconfig
mips lemote2f_defconfig
mips ar7_defconfig
sparc sparc64_defconfig
arc defconfig
sh urquell_defconfig
sh ecovec24_defconfig
powerpc pq2fads_defconfig
powerpc socrates_defconfig
arm corgi_defconfig
powerpc ppc64_defconfig
powerpc taishan_defconfig
mips ci20_defconfig
arc nsimosci_hs_defconfig
xtensa audio_kc705_defconfig
mips rbtx49xx_defconfig
arm mps2_defconfig
c6x evmc6474_defconfig
arm spear3xx_defconfig
mips rb532_defconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
c6x allyesconfig
nds32 defconfig
nios2 allyesconfig
csky defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
sh allmodconfig
parisc defconfig
s390 allyesconfig
parisc allyesconfig
i386 allyesconfig
sparc allyesconfig
sparc defconfig
i386 defconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
x86_64 randconfig-a006-20201120
x86_64 randconfig-a003-20201120
x86_64 randconfig-a004-20201120
x86_64 randconfig-a005-20201120
x86_64 randconfig-a001-20201120
x86_64 randconfig-a002-20201120
i386 randconfig-a004-20201123
i386 randconfig-a003-20201123
i386 randconfig-a002-20201123
i386 randconfig-a005-20201123
i386 randconfig-a001-20201123
i386 randconfig-a006-20201123
i386 randconfig-a004-20201120
i386 randconfig-a003-20201120
i386 randconfig-a002-20201120
i386 randconfig-a005-20201120
i386 randconfig-a001-20201120
i386 randconfig-a006-20201120
x86_64 randconfig-a015-20201123
x86_64 randconfig-a011-20201123
x86_64 randconfig-a014-20201123
x86_64 randconfig-a016-20201123
x86_64 randconfig-a012-20201123
x86_64 randconfig-a013-20201123
i386 randconfig-a012-20201120
i386 randconfig-a013-20201120
i386 randconfig-a011-20201120
i386 randconfig-a016-20201120
i386 randconfig-a014-20201120
i386 randconfig-a015-20201120
i386 randconfig-a012-20201123
i386 randconfig-a013-20201123
i386 randconfig-a011-20201123
i386 randconfig-a016-20201123
i386 randconfig-a014-20201123
i386 randconfig-a015-20201123
riscv nommu_k210_defconfig
riscv allyesconfig
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
x86_64 rhel
x86_64 allyesconfig
x86_64 rhel-7.6-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
clang tested configs:
x86_64 randconfig-a006-20201123
x86_64 randconfig-a003-20201123
x86_64 randconfig-a004-20201123
x86_64 randconfig-a005-20201123
x86_64 randconfig-a002-20201123
x86_64 randconfig-a001-20201123
x86_64 randconfig-a015-20201120
x86_64 randconfig-a011-20201120
x86_64 randconfig-a014-20201120
x86_64 randconfig-a016-20201120
x86_64 randconfig-a012-20201120
x86_64 randconfig-a013-20201120
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ 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