* Re: [PATCH v2 04/12] docs: x86: Add documentation for SVA (Shared Virtual Addressing)
From: Lu Baolu @ 2020-06-13 12:17 UTC (permalink / raw)
To: Fenghua Yu, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H Peter Anvin, David Woodhouse, Frederic Barrat, Andrew Donnellan,
Felix Kuehling, Joerg Roedel, Dave Hansen, Tony Luck, Ashok Raj,
Jacob Jun Pan, Dave Jiang, Yu-cheng Yu, Sohil Mehta,
Ravi V Shankar
Cc: x86, linux-kernel, amd-gfx, iommu, linuxppc-dev, baolu.lu
In-Reply-To: <1592008893-9388-5-git-send-email-fenghua.yu@intel.com>
Hi Fenghua,
On 2020/6/13 8:41, Fenghua Yu wrote:
> From: Ashok Raj <ashok.raj@intel.com>
>
> ENQCMD and Data Streaming Accelerator (DSA) and all of their associated
> features are a complicated stack with lots of interconnected pieces.
> This documentation provides a big picture overview for all of the
> features.
>
> Signed-off-by: Ashok Raj <ashok.raj@intel.com>
> Co-developed-by: Fenghua Yu <fenghua.yu@intel.com>
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> Reviewed-by: Tony Luck <tony.luck@intel.com>
> ---
> v2:
> - Fix the doc format and add the doc in toctree (Thomas)
> - Modify the doc for better description (Thomas, Tony, Dave)
>
> Documentation/x86/index.rst | 1 +
> Documentation/x86/sva.rst | 287 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 288 insertions(+)
> create mode 100644 Documentation/x86/sva.rst
>
> diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
> index 265d9e9a093b..e5d5ff096685 100644
> --- a/Documentation/x86/index.rst
> +++ b/Documentation/x86/index.rst
> @@ -30,3 +30,4 @@ x86-specific Documentation
> usb-legacy-support
> i386/index
> x86_64/index
> + sva
> diff --git a/Documentation/x86/sva.rst b/Documentation/x86/sva.rst
> new file mode 100644
> index 000000000000..1e52208c7dda
> --- /dev/null
> +++ b/Documentation/x86/sva.rst
> @@ -0,0 +1,287 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +===========================================
> +Shared Virtual Addressing (SVA) with ENQCMD
> +===========================================
> +
> +Background
> +==========
> +
> +Shared Virtual Addressing (SVA) allows the processor and device to use the
> +same virtual addresses avoiding the need for software to translate virtual
> +addresses to physical addresses. SVA is what PCIe calls Shared Virtual
> +Memory (SVM)
> +
> +In addition to the convenience of using application virtual addresses
> +by the device, it also doesn't require pinning pages for DMA.
> +PCIe Address Translation Services (ATS) along with Page Request Interface
> +(PRI) allow devices to function much the same way as the CPU handling
> +application page-faults. For more information please refer to PCIe
> +specification Chapter 10: ATS Specification.
> +
> +Use of SVA requires IOMMU support in the platform. IOMMU also is required
> +to support PCIe features ATS and PRI. ATS allows devices to cache
> +translations for the virtual address. IOMMU driver uses the mmu_notifier()
> +support to keep the device tlb cache and the CPU cache in sync. PRI allows
> +the device to request paging the virtual address before using if they are
> +not paged in the CPU page tables.
> +
> +
> +Shared Hardware Workqueues
> +==========================
> +
> +Unlike Single Root I/O Virtualization (SRIOV), Scalable IOV (SIOV) permits
> +the use of Shared Work Queues (SWQ) by both applications and Virtual
> +Machines (VM's). This allows better hardware utilization vs. hard
> +partitioning resources that could result in under utilization. In order to
> +allow the hardware to distinguish the context for which work is being
> +executed in the hardware by SWQ interface, SIOV uses Process Address Space
> +ID (PASID), which is a 20bit number defined by the PCIe SIG.
> +
> +PASID value is encoded in all transactions from the device. This allows the
> +IOMMU to track I/O on a per-PASID granularity in addition to using the PCIe
> +Resource Identifier (RID) which is the Bus/Device/Function.
> +
> +
> +ENQCMD
> +======
> +
> +ENQCMD is a new instruction on Intel platforms that atomically submits a
> +work descriptor to a device. The descriptor includes the operation to be
> +performed, virtual addresses of all parameters, virtual address of a completion
> +record, and the PASID (process address space ID) of the current process.
> +
> +ENQCMD works with non-posted semantics and carries a status back if the
> +command was accepted by hardware. This allows the submitter to know if the
> +submission needs to be retried or other device specific mechanisms to
> +implement implement fairness or ensure forward progress can be made.
Repeated "implement".
> +
> +ENQCMD is the glue that ensures applications can directly submit commands
> +to the hardware and also permit hardware to be aware of application context
> +to perform I/O operations via use of PASID.
> +
> +Process Address Space Tagging
> +=============================
> +
> +A new thread scoped MSR (IA32_PASID) provides the connection between
> +user processes and the rest of the hardware. When an application first
> +accesses an SVA capable device this MSR is initialized with a newly
> +allocated PASID. The driver for the device calls an IOMMU specific api
> +that sets up the routing for DMA and page-requests.
> +
> +For example, the Intel Data Streaming Accelerator (DSA) uses
> +intel_svm_bind_mm(), which will do the following.
The Intel SVM APIs have been deprecated. Drivers should use
iommu_sva_bind_device() instead. Please also update other places in
this document.
> +
> +- Allocate the PASID, and program the process page-table (cr3) in the PASID
> + context entries.
> +- Register for mmu_notifier() to track any page-table invalidations to keep
> + the device tlb in sync. For example, when a page-table entry is invalidated,
> + IOMMU propagates the invalidation to device tlb. This will force any
> + future access by the device to this virtual address to participate in
> + ATS. If the IOMMU responds with proper response that a page is not
> + present, the device would request the page to be paged in via the PCIe PRI
> + protocol before performing I/O.
> +
> +This MSR is managed with the XSAVE feature set as "supervisor state" to
> +ensure the MSR is updated during context switch.
> +
> +PASID Management
> +================
> +
> +The kernel must allocate a PASID on behalf of each process and program it
> +into the new MSR to communicate the process identity to platform hardware.
> +ENQCMD uses the PASID stored in this MSR to tag requests from this process.
> +When a user submits a work descriptor to a device using the ENQCMD
> +instruction, the PASID field in the descriptor is auto-filled with the
> +value from MSR_IA32_PASID. Requests for DMA from the device are also tagged
> +with the same PASID. The platform IOMMU uses the PASID in the transaction to
> +perform address translation. The IOMMU api's setup the corresponding PASID
> +entry in IOMMU with the process address used by the CPU (for e.g cr3 in x86).
> +
> +The MSR must be configured on each logical CPU before any application
> +thread can interact with a device. Threads that belong to the same
> +process share the same page tables, thus the same MSR value.
> +
> +PASID is cleared when a process is created. The PASID allocation and MSR
> +programming may occur long after a process and its threads have been created.
> +One thread must call bind() to allocate the PASID for the process. If a
> +thread uses ENQCMD without the MSR first being populated, it will cause #GP.
> +The kernel will fix up the #GP by writing the process-wide PASID into the
> +thread that took the #GP. A single process PASID can be used simultaneously
> +with multiple devices since they all share the same address space.
> +
> +New threads could inherit the MSR value from the parent. But this would
> +involve additional state management for those threads which may never use
> +ENQCMD. Clearing the MSR at thread creation permits all threads to have a
> +consistent behavior; the PASID is only programmed when the thread calls
> +the bind() api (intel_svm_bind_mm()()), or when a thread calls ENQCMD for
> +the first time.
> +
> +PASID Lifecycle Management
> +==========================
> +
> +Only processes that access SVA capable devices need to have a PASID
> +allocated. This allocation happens when a process first opens an SVA
> +capable device (subsequent opens of the same, or other devices will
> +share the same PASID).
> +
> +Although the PASID is allocated to the process by opening a device,
> +it is not active in any of the threads of that process. Activation is
> +done lazily when a thread tries to submit a work descriptor to a device
> +using the ENQCMD.
> +
> +That first access will trigger a #GP fault because the IA32_PASID MSR
> +has not been initialized with the PASID value assigned to the process
> +when the device was opened. The Linux #GP handler notes that a PASID as
> +been allocated for the process, and so initializes the IA32_PASID MSR
> +and returns so that the ENQCMD instruction is re-executed.
> +
> +On fork(2) or exec(2) the PASID is removed from the process as it no
> +longer has the same address space that it had when the device was opened.
> +
> +On clone(2) the new task shares the same address space, so will be
> +able to use the PASID allocated to the process. The IA32_PASID is not
> +preemptively initialized as the kernel does not know whether this thread
> +is going to access the device.
> +
> +On exit(2) the PASID is freed. The device driver ensures that any pending
> +operations queued to the device are either completed or aborted before
> +allowing the PASID to be re-allocated.
reallocated
> +
> +Relationships
> +=============
> +
> + * Each process has many threads, but only one PASID
> + * Devices have a limited number (~10's to 1000's) of hardware
> + workqueues and each portal maps down to a single workqueue.
> + The device driver manages allocating hardware workqueues.
> + * A single mmap() maps a single hardware workqueue as a "portal"
> + * For each device with which a process interacts, there must be
> + one or more mmap()'d portals.
> + * Many threads within a process can share a single portal to access
> + a single device.
> + * Multiple processes can separately mmap() the same portal, in
> + which case they still share one device hardware workqueue.
> + * The single process-wide PASID is used by all threads to interact
> + with all devices. There is not, for instance, a PASID for each
> + thread or each thread<->device pair.
> +
> +FAQ
> +===
> +
> +* What is SVA/SVM?
> +
> +Shared Virtual Addressing (SVA) permits I/O hardware and the processor to
> +work in the same address space. In short, sharing the address space. Some
> +call it Shared Virtual Memory (SVM), but Linux community wanted to avoid
> +it with Posix Shared Memory and Secure Virtual Machines which were terms
> +already in circulation.
> +
> +* What is a PASID?
> +
> +A Process Address Space ID (PASID) is a PCIe-defined TLP Prefix. A PASID is
> +a 20 bit number allocated and managed by the OS. PASID is included in all
> +transactions between the platform and the device.
> +
> +* How are shared work queues different?
> +
> +Traditionally to allow user space applications interact with hardware,
> +there is a separate instance required per process. For example, consider
> +doorbells as a mechanism of informing hardware about work to process. Each
> +doorbell is required to be spaced 4k (or page-size) apart for process
> +isolation. This requires hardware to provision that space and reserve in
> +MMIO. This doesn't scale as the number of threads becomes quite large. The
> +hardware also manages the queue depth for Shared Work Queues (SWQ), and
> +consumers don't need to track queue depth. If there is no space to accept
> +a command, the device will return an error indicating retry. Also
> +submitting a command to an MMIO address that can't accept ENQCMD will
> +return retry in response. In the new DMWr PCIe terminology, devices need to
> +support DMWr completer capability. In addition it requires all switch ports
> +to support DMWr routing and must be enabled by the PCIe subsystem, much
> +like how PCIe Atomics() are managed for instance.
> +
> +SWQ allows hardware to provision just a single address in the device. When
> +used with ENQCMD to submit work, the device can distinguish the process
> +submitting the work since it will include the PASID assigned to that
> +process. This decreases the pressure of hardware requiring to support
> +hardware to scale to a large number of processes.
> +
> +* Is this the same as a user space device driver?
> +
> +Communicating with the device via the shared work queue is much simpler
> +than a full blown user space driver. The kernel driver does all the
> +initialization of the hardware. User space only needs to worry about
> +submitting work and processing completions.
> +
> +* Is this the same as SR-IOV?
> +
> +Single Root I/O Virtualization (SR-IOV) focuses on providing independent
> +hardware interfaces for virtualizing hardware. Hence its required to be
> +almost fully functional interface to software supporting the traditional
> +BAR's, space for interrupts via MSI-x, its own register layout.
> +Virtual Functions (VFs) are assisted by the Physical Function (PF)
> +driver.
> +
> +Scalable I/O Virtualization builds on the PASID concept to create device
> +instances for virtualization. SIOV requires host software to assist in
> +creating virtual devices, each virtual device is represented by a PASID
> +along with the BDF of the device. This allows device hardware to optimize
> +device resource creation and can grow dynamically on demand. SR-IOV creation
> +and management is very static in nature. Consult references below for more
> +details.
> +
> +* Why not just create a virtual function for each app?
> +
> +Creating PCIe SRIOV type virtual functions (VF) are expensive. They create
> +duplicated hardware for PCI config space requirements, Interrupts such as
> +MSIx for instance. Resources such as interrupts have to be hard partitioned
> +between VF's at creation time, and cannot scale dynamically on demand. The
> +VF's are not completely independent from the Physical function (PF). Most
> +VF's require some communication and assistance from the PF driver. SIOV
> +creates a software defined device. Where all the configuration and control
> +aspects are mediated via the slow path. The work submission and completion
> +happen without any mediation.
> +
> +* Does this support virtualization?
> +
> +ENQCMD can be used from within a guest VM. In these cases the VMM helps
> +with setting up a translation table to translate from Guest PASID to Host
> +PASID. Please consult the ENQCMD instruction set reference for more
> +details.
> +
> +* Does memory need to be pinned?
> +
> +When devices support SVA, along with platform hardware such as IOMMU
> +supporting such devices, there is no need to pin memory for DMA purposes.
> +Devices that support SVA also support other PCIe features that remove the
> +pinning requirement for memory.
> +
> +Device TLB support - Device requests the IOMMU to lookup an address before
> +use via Address Translation Service (ATS) requests. If the mapping exists
> +but there is no page allocated by the OS, IOMMU hardware returns that no
> +mapping exists.
> +
> +Device requests that virtual address to be mapped via Page Request
> +Interface (PRI). Once the OS has successfully completed the mapping, it
> +returns the response back to the device. The device continues again to
> +request for a translation and continues.
> +
> +IOMMU works with the OS in managing consistency of page-tables with the
> +device. When removing pages, it interacts with the device to remove any
> +device-tlb that might have been cached before removing the mappings from
> +the OS.
> +
> +References
> +==========
> +
> +VT-D:
> +https://01.org/blogs/ashokraj/2018/recent-enhancements-intel-virtualization-technology-directed-i/o-intel-vt-d
> +
> +SIOV:
> +https://01.org/blogs/2019/assignable-interfaces-intel-scalable-i/o-virtualization-linux
> +
> +ENQCMD in ISE:
> +https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
> +
> +DSA spec:
> +https://software.intel.com/sites/default/files/341204-intel-data-streaming-accelerator-spec.pdf
>
Best regards,
baolu
^ permalink raw reply
* Re: [PATCH v2 11/12] x86/mmu: Allocate/free PASID
From: Lu Baolu @ 2020-06-13 13:07 UTC (permalink / raw)
To: Fenghua Yu, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
H Peter Anvin, David Woodhouse, Frederic Barrat, Andrew Donnellan,
Felix Kuehling, Joerg Roedel, Dave Hansen, Tony Luck, Ashok Raj,
Jacob Jun Pan, Dave Jiang, Yu-cheng Yu, Sohil Mehta,
Ravi V Shankar
Cc: x86, linux-kernel, amd-gfx, iommu, linuxppc-dev, baolu.lu
In-Reply-To: <1592008893-9388-12-git-send-email-fenghua.yu@intel.com>
Hi Fenghua,
On 2020/6/13 8:41, Fenghua Yu wrote:
> A PASID is allocated for an "mm" the first time any thread attaches
> to an SVM capable device. Later device attachments (whether to the same
> device or another SVM device) will re-use the same PASID.
>
> The PASID is freed when the process exits (so no need to keep
> reference counts on how many SVM devices are sharing the PASID).
FYI.
Jean-Philippe Brucker has a patch for mm->pasid management in the vendor
agnostic manner.
https://www.spinics.net/lists/iommu/msg44459.html
Best regards,
baolu
>
> Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
> Reviewed-by: Tony Luck <tony.luck@intel.com>
> ---
> v2:
> - Define a helper free_bind() to simplify error exit code in bind_mm()
> (Thomas)
> - Fix a ret error code in bind_mm() (Thomas)
> - Change pasid's type from "int" to "unsigned int" to have consistent
> pasid type in iommu (Thomas)
> - Simplify alloc_pasid() a bit.
>
> arch/x86/include/asm/iommu.h | 2 +
> arch/x86/include/asm/mmu_context.h | 14 ++++
> drivers/iommu/intel/svm.c | 101 +++++++++++++++++++++++++----
> 3 files changed, 105 insertions(+), 12 deletions(-)
>
> diff --git a/arch/x86/include/asm/iommu.h b/arch/x86/include/asm/iommu.h
> index bf1ed2ddc74b..ed41259fe7ac 100644
> --- a/arch/x86/include/asm/iommu.h
> +++ b/arch/x86/include/asm/iommu.h
> @@ -26,4 +26,6 @@ arch_rmrr_sanity_check(struct acpi_dmar_reserved_memory *rmrr)
> return -EINVAL;
> }
>
> +void __free_pasid(struct mm_struct *mm);
> +
> #endif /* _ASM_X86_IOMMU_H */
> diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
> index 47562147e70b..f8c91ce8c451 100644
> --- a/arch/x86/include/asm/mmu_context.h
> +++ b/arch/x86/include/asm/mmu_context.h
> @@ -13,6 +13,7 @@
> #include <asm/tlbflush.h>
> #include <asm/paravirt.h>
> #include <asm/debugreg.h>
> +#include <asm/iommu.h>
>
> extern atomic64_t last_mm_ctx_id;
>
> @@ -117,9 +118,22 @@ static inline int init_new_context(struct task_struct *tsk,
> init_new_context_ldt(mm);
> return 0;
> }
> +
> +static inline void free_pasid(struct mm_struct *mm)
> +{
> + if (!IS_ENABLED(CONFIG_INTEL_IOMMU_SVM))
> + return;
> +
> + if (!cpu_feature_enabled(X86_FEATURE_ENQCMD))
> + return;
> +
> + __free_pasid(mm);
> +}
> +
> static inline void destroy_context(struct mm_struct *mm)
> {
> destroy_context_ldt(mm);
> + free_pasid(mm);
> }
>
> extern void switch_mm(struct mm_struct *prev, struct mm_struct *next,
> diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
> index 4e775e12ae52..27dc866b8461 100644
> --- a/drivers/iommu/intel/svm.c
> +++ b/drivers/iommu/intel/svm.c
> @@ -425,6 +425,53 @@ int intel_svm_unbind_gpasid(struct device *dev, unsigned int pasid)
> return ret;
> }
>
> +static void free_bind(struct intel_svm *svm, struct intel_svm_dev *sdev,
> + bool new_pasid)
> +{
> + if (new_pasid)
> + ioasid_free(svm->pasid);
> + kfree(svm);
> + kfree(sdev);
> +}
> +
> +/*
> + * If this mm already has a PASID, use it. Otherwise allocate a new one.
> + * Let the caller know if a new PASID is allocated via 'new_pasid'.
> + */
> +static int alloc_pasid(struct intel_svm *svm, struct mm_struct *mm,
> + unsigned int pasid_max, bool *new_pasid,
> + unsigned int flags)
> +{
> + unsigned int pasid;
> +
> + *new_pasid = false;
> +
> + /*
> + * Reuse the PASID if the mm already has a PASID and not a private
> + * PASID is requested.
> + */
> + if (mm && mm->pasid && !(flags & SVM_FLAG_PRIVATE_PASID)) {
> + /*
> + * Once a PASID is allocated for this mm, the PASID
> + * stays with the mm until the mm is dropped. Reuse
> + * the PASID which has been already allocated for the
> + * mm instead of allocating a new one.
> + */
> + ioasid_set_data(mm->pasid, svm);
> +
> + return mm->pasid;
> + }
> +
> + /* Allocate a new pasid. Do not use PASID 0, reserved for init PASID. */
> + pasid = ioasid_alloc(NULL, PASID_MIN, pasid_max - 1, svm);
> + if (pasid != INVALID_IOASID) {
> + /* A new pasid is allocated. */
> + *new_pasid = true;
> + }
> +
> + return pasid;
> +}
> +
> /* Caller must hold pasid_mutex, mm reference */
> static int
> intel_svm_bind_mm(struct device *dev, unsigned int flags,
> @@ -518,6 +565,8 @@ intel_svm_bind_mm(struct device *dev, unsigned int flags,
> init_rcu_head(&sdev->rcu);
>
> if (!svm) {
> + bool new_pasid;
> +
> svm = kzalloc(sizeof(*svm), GFP_KERNEL);
> if (!svm) {
> ret = -ENOMEM;
> @@ -529,12 +578,9 @@ intel_svm_bind_mm(struct device *dev, unsigned int flags,
> if (pasid_max > intel_pasid_max_id)
> pasid_max = intel_pasid_max_id;
>
> - /* Do not use PASID 0, reserved for RID to PASID */
> - svm->pasid = ioasid_alloc(NULL, PASID_MIN,
> - pasid_max - 1, svm);
> + svm->pasid = alloc_pasid(svm, mm, pasid_max, &new_pasid, flags);
> if (svm->pasid == INVALID_IOASID) {
> - kfree(svm);
> - kfree(sdev);
> + free_bind(svm, sdev, new_pasid);
> ret = -ENOSPC;
> goto out;
> }
> @@ -547,9 +593,7 @@ intel_svm_bind_mm(struct device *dev, unsigned int flags,
> if (mm) {
> ret = mmu_notifier_register(&svm->notifier, mm);
> if (ret) {
> - ioasid_free(svm->pasid);
> - kfree(svm);
> - kfree(sdev);
> + free_bind(svm, sdev, new_pasid);
> goto out;
> }
> }
> @@ -565,12 +609,18 @@ intel_svm_bind_mm(struct device *dev, unsigned int flags,
> if (ret) {
> if (mm)
> mmu_notifier_unregister(&svm->notifier, mm);
> - ioasid_free(svm->pasid);
> - kfree(svm);
> - kfree(sdev);
> + free_bind(svm, sdev, new_pasid);
> goto out;
> }
>
> + if (mm && new_pasid && !(flags & SVM_FLAG_PRIVATE_PASID)) {
> + /*
> + * Track the new pasid in the mm. The pasid will be
> + * freed at process exit. Don't track requested
> + * private PASID in the mm.
> + */
> + mm->pasid = svm->pasid;
> + }
> list_add_tail(&svm->list, &global_svm_list);
> } else {
> /*
> @@ -640,7 +690,8 @@ static int intel_svm_unbind_mm(struct device *dev, unsigned int pasid)
> kfree_rcu(sdev, rcu);
>
> if (list_empty(&svm->devs)) {
> - ioasid_free(svm->pasid);
> + /* Clear data in the pasid. */
> + ioasid_set_data(pasid, NULL);
> if (svm->mm)
> mmu_notifier_unregister(&svm->notifier, svm->mm);
> list_del(&svm->list);
> @@ -1001,3 +1052,29 @@ unsigned int intel_svm_get_pasid(struct iommu_sva *sva)
>
> return pasid;
> }
> +
> +/*
> + * An invalid pasid is either 0 (init PASID value) or bigger than max PASID
> + * (PASID_MAX - 1).
> + */
> +static bool invalid_pasid(unsigned int pasid)
> +{
> + return (pasid == INIT_PASID) || (pasid >= PASID_MAX);
> +}
> +
> +/* On process exit free the PASID (if one was allocated). */
> +void __free_pasid(struct mm_struct *mm)
> +{
> + unsigned int pasid = mm->pasid;
> +
> + /* No need to free invalid pasid. */
> + if (invalid_pasid(pasid))
> + return;
> +
> + /*
> + * Since the pasid is not bound to any svm by now, there is no race
> + * here with binding/unbinding and no need to protect the free
> + * operation by pasid_mutex.
> + */
> + ioasid_free(pasid);
> +}
>
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.8-2 tag
From: Michael Ellerman @ 2020-06-13 13:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: aik, linuxppc-dev, linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Linus,
Please pull a powerpc fix for 5.8:
The following changes since commit 7ae77150d94d3b535c7b85e6b3647113095e79bf:
Merge tag 'powerpc-5.8-1' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2020-06-05 12:39:30 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.8-2
for you to fetch changes up to e881bfaf5a5f409390973e076333281465f2b0d9:
KVM: PPC: Fix nested guest RC bits update (2020-06-12 16:19:53 +1000)
- ------------------------------------------------------------------
powerpc fixes for 5.8 #2
One fix for a recent change which broke nested KVM guests on Power9.
Thanks to:
Alexey Kardashevskiy.
- ------------------------------------------------------------------
Alexey Kardashevskiy (1):
KVM: PPC: Fix nested guest RC bits update
arch/powerpc/kvm/book3s_hv_nested.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAl7k2b0ACgkQUevqPMjh
pYDmPQ/9Ffq4hgIdiJdzusd9tYEynumET8/cfRLYCmUVEkYQdpgpLgp/XnNFq/fg
CqqDN173ioTg5xN1QEZkcPKFwOqmlG2oYJI4s93nMAINmuCE7h4bsrGLOZNPIx1G
FD2v0piGkxmxRud1Qt7+cpIfbbw3wKnFqOQ1yzRop/weufp42PSUD00cY6DUa9Ip
LKWxBcje6yl56U+z31iWvDjNxP2cwZUz79ioKQG7YDigQh+aSVFaZ1NboA5fjde0
CSm0DrHfhPjlZTw2y3IvTbETCi7wU1dIrElf6e8RMsIOCg1UeUeiOsHP80fHnMFA
NP1JlsIEPjIxUb9cJ7Uc03wwUMioQcx7ZwISTWP6aQZx20nEdcFErqleCLr8e/KC
beWRz7TMfCG3v6GQv5yJKx+/AB8XWYcBe+X/8+7AAZS51DFHU4xvxIy9B43a3cCe
UozRzo/OTVvRvRPsM4TaIIZNPBV/WWm/+CwEZgGEOBqXK+ZQpwkDh5kP5P/nWv0g
HoK82XTGdMDokKuH+oStuo9kpMbj7ktJhOVFply8axXdQ9Jn2y/4t1mH4jsodza5
OWqpDDnRXzOlTasWBPIcdgmriYeJfEQ5rDmxRXfoqBTEoSVt2TC3e1ooN0IkCVcy
pPROKGvRHdfqMvXqwoDpLL3wF43u439bl8ROBC89nsxdpcBixoM=
=VRzv
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] powerpc/fsl_booke/32: fix build with CONFIG_RANDOMIZE_BASE
From: Christophe Leroy @ 2020-06-13 17:28 UTC (permalink / raw)
To: Arseny Solokha, Michael Ellerman, Jason Yan, linuxppc-dev
Cc: Scott Wood, Christophe Leroy, linux-kernel, stable
In-Reply-To: <20200613162801.1946619-1-asolokha@kb.kras.ru>
Le 13/06/2020 à 18:28, Arseny Solokha a écrit :
> Building the current 5.8 kernel for a e500 machine with
> CONFIG_RANDOMIZE_BASE set yields the following failure:
>
> arch/powerpc/mm/nohash/kaslr_booke.c: In function 'kaslr_early_init':
> arch/powerpc/mm/nohash/kaslr_booke.c:387:2: error: implicit declaration
> of function 'flush_icache_range'; did you mean 'flush_tlb_range'?
> [-Werror=implicit-function-declaration]
>
> Indeed, including asm/cacheflush.h into kaslr_booke.c fixes the build.
>
> The issue dates back to the introduction of that file and probably went
> unnoticed because there's no in-tree defconfig with CONFIG_RANDOMIZE_BASE
> set.
I don't get this problem with mpc85xx_defconfig + RELOCATABLE +
RANDOMIZE_BASE.
Christophe
>
> Fixes: 2b0e86cc5de6 ("powerpc/fsl_booke/32: implement KASLR infrastructure")
> Cc: stable@vger.kernel.org
> Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
> ---
> arch/powerpc/mm/nohash/kaslr_booke.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/mm/nohash/kaslr_booke.c b/arch/powerpc/mm/nohash/kaslr_booke.c
> index 4a75f2d9bf0e..bce0e5349978 100644
> --- a/arch/powerpc/mm/nohash/kaslr_booke.c
> +++ b/arch/powerpc/mm/nohash/kaslr_booke.c
> @@ -14,6 +14,7 @@
> #include <linux/memblock.h>
> #include <linux/libfdt.h>
> #include <linux/crash_core.h>
> +#include <asm/cacheflush.h>
> #include <asm/pgalloc.h>
> #include <asm/prom.h>
> #include <asm/kdump.h>
>
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.8-2 tag
From: pr-tracker-bot @ 2020-06-13 18:00 UTC (permalink / raw)
To: Michael Ellerman; +Cc: aik, linuxppc-dev, Linus Torvalds, linux-kernel
In-Reply-To: <87y2ordqcm.fsf@mpe.ellerman.id.au>
The pull request you sent on Sat, 13 Jun 2020 23:53:29 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.8-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/08bf1a27c4c354b853fd81a79e953525bbcc8506
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* [PATCH] powerpc/fsl_booke/32: fix build with CONFIG_RANDOMIZE_BASE
From: Arseny Solokha @ 2020-06-13 16:28 UTC (permalink / raw)
To: Michael Ellerman, Jason Yan, linuxppc-dev
Cc: Scott Wood, Christophe Leroy, Arseny Solokha, linux-kernel,
stable
Building the current 5.8 kernel for a e500 machine with
CONFIG_RANDOMIZE_BASE set yields the following failure:
arch/powerpc/mm/nohash/kaslr_booke.c: In function 'kaslr_early_init':
arch/powerpc/mm/nohash/kaslr_booke.c:387:2: error: implicit declaration
of function 'flush_icache_range'; did you mean 'flush_tlb_range'?
[-Werror=implicit-function-declaration]
Indeed, including asm/cacheflush.h into kaslr_booke.c fixes the build.
The issue dates back to the introduction of that file and probably went
unnoticed because there's no in-tree defconfig with CONFIG_RANDOMIZE_BASE
set.
Fixes: 2b0e86cc5de6 ("powerpc/fsl_booke/32: implement KASLR infrastructure")
Cc: stable@vger.kernel.org
Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
---
arch/powerpc/mm/nohash/kaslr_booke.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/mm/nohash/kaslr_booke.c b/arch/powerpc/mm/nohash/kaslr_booke.c
index 4a75f2d9bf0e..bce0e5349978 100644
--- a/arch/powerpc/mm/nohash/kaslr_booke.c
+++ b/arch/powerpc/mm/nohash/kaslr_booke.c
@@ -14,6 +14,7 @@
#include <linux/memblock.h>
#include <linux/libfdt.h>
#include <linux/crash_core.h>
+#include <asm/cacheflush.h>
#include <asm/pgalloc.h>
#include <asm/prom.h>
#include <asm/kdump.h>
--
2.27.0
^ permalink raw reply related
* Re: [PATCH] powerpc/fsl_booke/32: fix build with CONFIG_RANDOMIZE_BASE
From: Arseny Solokha @ 2020-06-13 21:20 UTC (permalink / raw)
To: Christophe Leroy
Cc: Christophe Leroy, Jason Yan, linux-kernel, stable, Scott Wood,
Arseny Solokha, linuxppc-dev
In-Reply-To: <754d31be-730b-8f18-4ead-ba2f303650d0@csgroup.eu>
> Le 13/06/2020 à 18:28, Arseny Solokha a écrit :
>> Building the current 5.8 kernel for a e500 machine with
>> CONFIG_RANDOMIZE_BASE set yields the following failure:
>>
>> arch/powerpc/mm/nohash/kaslr_booke.c: In function 'kaslr_early_init':
>> arch/powerpc/mm/nohash/kaslr_booke.c:387:2: error: implicit declaration
>> of function 'flush_icache_range'; did you mean 'flush_tlb_range'?
>> [-Werror=implicit-function-declaration]
>>
>> Indeed, including asm/cacheflush.h into kaslr_booke.c fixes the build.
>>
>> The issue dates back to the introduction of that file and probably went
>> unnoticed because there's no in-tree defconfig with CONFIG_RANDOMIZE_BASE
>> set.
>
> I don't get this problem with mpc85xx_defconfig + RELOCATABLE +
> RANDOMIZE_BASE.
Ah, OK. So the critical difference between mpc85xx_defconfig and our custom
config is that the former sets CONFIG_BLOCK while ours doesn't. Then we have the
following dependence chain:
arch/powerpc/mm/nohash/kaslr_booke.c
include/linux/swap.h
include/linux/memcontrol.h
include/linux/writeback.h
include/linux/blk-cgroup.h
include/linux/blkdev.h
#ifdef CONFIG_BLOCK
#include <linux/pagemap.h>
#endif
include/linux/pagemap.h
include/linux/highmem.h
arch/powerpc/include/asm/cacheflush.h
and that's how the latter doesn't get included in
arch/powerpc/mm/nohash/kaslr_booke.c, because in our config CONFIG_BLOCK is not
defined in the first place.
Arseny
> Christophe
>
>>
>> Fixes: 2b0e86cc5de6 ("powerpc/fsl_booke/32: implement KASLR infrastructure")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
>> ---
>> arch/powerpc/mm/nohash/kaslr_booke.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/powerpc/mm/nohash/kaslr_booke.c b/arch/powerpc/mm/nohash/kaslr_booke.c
>> index 4a75f2d9bf0e..bce0e5349978 100644
>> --- a/arch/powerpc/mm/nohash/kaslr_booke.c
>> +++ b/arch/powerpc/mm/nohash/kaslr_booke.c
>> @@ -14,6 +14,7 @@
>> #include <linux/memblock.h>
>> #include <linux/libfdt.h>
>> #include <linux/crash_core.h>
>> +#include <asm/cacheflush.h>
>> #include <asm/pgalloc.h>
>> #include <asm/prom.h>
>> #include <asm/kdump.h>
>>
^ permalink raw reply
* Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver
From: Finn Thain @ 2020-06-14 0:03 UTC (permalink / raw)
To: Chris Boot
Cc: Bart Van Assche, linux-scsi, Chuhong Yuan, linux-kernel,
Nicholas Bellinger, target-devel, Martin K . Petersen,
linux1394-devel, linuxppc-dev, Stefan Richter
In-Reply-To: <01020172acd3d10f-3964f076-a820-43fc-9494-3f3946e9b7b5-000000@eu-west-1.amazonses.com>
On Sat, 13 Jun 2020, Chris Boot wrote:
> I no longer have the time to maintain this subsystem nor the hardware to
> test patches with.
Then why not patch MAINTAINERS, and orphan it, as per usual practice?
$ git log --oneline MAINTAINERS | grep -i orphan
> It also doesn't appear to have any active users so I doubt anyone will
> miss it.
>
It's not unusual that any Linux driver written more than 5 years ago
"doesn't appear to have any active users".
If a driver has been orphaned and broken in the past, and no-one stepped
up to fix it within a reasonable period, removal would make sense. But
that's not the case here.
I haven't used this driver for a long time, but I still own PowerMacs with
firewire, and I know I'm not the only one.
> Signed-off-by: Chris Boot <bootc@bootc.net>
> ---
> MAINTAINERS | 9 -
> drivers/target/Kconfig | 1 -
> drivers/target/Makefile | 1 -
> drivers/target/sbp/Kconfig | 12 -
> drivers/target/sbp/Makefile | 2 -
> drivers/target/sbp/sbp_target.c | 2350 -------------------------------
> drivers/target/sbp/sbp_target.h | 243 ----
> 7 files changed, 2618 deletions(-)
> delete mode 100644 drivers/target/sbp/Kconfig
> delete mode 100644 drivers/target/sbp/Makefile
> delete mode 100644 drivers/target/sbp/sbp_target.c
> delete mode 100644 drivers/target/sbp/sbp_target.h
>
^ permalink raw reply
* [PATCH] powerpc/powernv/pci: add ifdef to avoid dead code
From: Greg Thelen @ 2020-06-14 5:54 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Oliver O'Halloran
Cc: Greg Thelen, linuxppc-dev, linux-kernel
Commit dc3d8f85bb57 ("powerpc/powernv/pci: Re-work bus PE
configuration") removed a couple pnv_ioda_setup_bus_dma() calls. The
only remaining calls are behind CONFIG_IOMMU_API. Thus builds without
CONFIG_IOMMU_API see:
arch/powerpc/platforms/powernv/pci-ioda.c:1888:13: error: 'pnv_ioda_setup_bus_dma' defined but not used
Add CONFIG_IOMMU_API ifdef guard to avoid dead code.
Fixes: dc3d8f85bb57 ("powerpc/powernv/pci: Re-work bus PE configuration")
Signed-off-by: Greg Thelen <gthelen@google.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 73a63efcf855..f7762052b7c4 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1885,6 +1885,7 @@ static bool pnv_pci_ioda_iommu_bypass_supported(struct pci_dev *pdev,
return false;
}
+#ifdef CONFIG_IOMMU_API
static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
{
struct pci_dev *dev;
@@ -1897,6 +1898,7 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
pnv_ioda_setup_bus_dma(pe, dev->subordinate);
}
}
+#endif
static inline __be64 __iomem *pnv_ioda_get_inval_reg(struct pnv_phb *phb,
bool real_mode)
--
2.27.0.290.gba653c62da-goog
^ permalink raw reply related
* Re: [PATCH] powerpc/powernv/pci: add ifdef to avoid dead code
From: Christophe Leroy @ 2020-06-14 7:26 UTC (permalink / raw)
To: Greg Thelen, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Oliver O'Halloran
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20200614055418.33497-1-gthelen@google.com>
Hi,
Le 14/06/2020 à 07:54, Greg Thelen a écrit :
> Commit dc3d8f85bb57 ("powerpc/powernv/pci: Re-work bus PE
> configuration") removed a couple pnv_ioda_setup_bus_dma() calls. The
> only remaining calls are behind CONFIG_IOMMU_API. Thus builds without
> CONFIG_IOMMU_API see:
> arch/powerpc/platforms/powernv/pci-ioda.c:1888:13: error: 'pnv_ioda_setup_bus_dma' defined but not used
>
> Add CONFIG_IOMMU_API ifdef guard to avoid dead code.
I think you should move the function down into the same ifdef as the
callers instead of adding a new ifdef.
Christophe
>
> Fixes: dc3d8f85bb57 ("powerpc/powernv/pci: Re-work bus PE configuration")
> Signed-off-by: Greg Thelen <gthelen@google.com>
> ---
> arch/powerpc/platforms/powernv/pci-ioda.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index 73a63efcf855..f7762052b7c4 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -1885,6 +1885,7 @@ static bool pnv_pci_ioda_iommu_bypass_supported(struct pci_dev *pdev,
> return false;
> }
>
> +#ifdef CONFIG_IOMMU_API
> static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
> {
> struct pci_dev *dev;
> @@ -1897,6 +1898,7 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
> pnv_ioda_setup_bus_dma(pe, dev->subordinate);
> }
> }
> +#endif
>
> static inline __be64 __iomem *pnv_ioda_get_inval_reg(struct pnv_phb *phb,
> bool real_mode)
>
^ permalink raw reply
* [PATCH] powerpc/perf: fix missing is_sier_aviable() during build
From: Madhavan Srinivasan @ 2020-06-14 8:36 UTC (permalink / raw)
To: mpe; +Cc: Aneesh Kumar K . V, Madhavan Srinivasan, linuxppc-dev
Compilation error:
arch/powerpc/perf/perf_regs.c:80:undefined reference to `.is_sier_available'
Currently is_sier_available() is part of core-book3s.c.
But then, core-book3s.c is added to build based on
CONFIG_PPC_PERF_CTRS. A config with CONFIG_PERF_EVENTS
and without CONFIG_PPC_PERF_CTRS will have a build break
because of missing is_sier_available(). Patch adds
is_sier_available() in asm/perf_event.h to fix the build
break for configs missing CONFIG_PPC_PERF_CTRS.
Fixes: 333804dc3b7a9 ('powerpc/perf: Update perf_regs structure to include SIER")
Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
---
arch/powerpc/include/asm/perf_event.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/perf_event.h b/arch/powerpc/include/asm/perf_event.h
index eed3954082fa..1e8b2e1ec1db 100644
--- a/arch/powerpc/include/asm/perf_event.h
+++ b/arch/powerpc/include/asm/perf_event.h
@@ -12,6 +12,8 @@
#ifdef CONFIG_PPC_PERF_CTRS
#include <asm/perf_event_server.h>
+#else
+static inline bool is_sier_available(void) { return false; }
#endif
#ifdef CONFIG_FSL_EMB_PERF_EVENT
--
2.26.2
^ permalink raw reply related
* Re: PowerPC KVM-PR issue
From: Nicholas Piggin @ 2020-06-14 8:50 UTC (permalink / raw)
To: Christian Zigotzky, kvm-ppc@vger.kernel.org, linuxppc-dev
Cc: Darren Stevens, R.T.Dickinson, Christian Zigotzky
In-Reply-To: <fffeb817-35e0-2562-b3cf-2fd476948c76@xenosoft.de>
Excerpts from Christian Zigotzky's message of June 12, 2020 11:01 pm:
> On 11 June 2020 at 04:47 pm, Christian Zigotzky wrote:
>> On 10 June 2020 at 01:23 pm, Christian Zigotzky wrote:
>>> On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:
>>>> On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:
>>>>> Hello,
>>>>>
>>>>> KVM-PR doesn't work anymore on my Nemo board [1]. I figured out
>>>>> that the Git kernels and the kernel 5.7 are affected.
>>>>>
>>>>> Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at
>>>>> 700 failed (00000000)
>>>>>
>>>>> I can boot virtual QEMU PowerPC machines with KVM-PR with the
>>>>> kernel 5.6 without any problems on my Nemo board.
>>>>>
>>>>> I tested it with QEMU 2.5.0 and QEMU 5.0.0 today.
>>>>>
>>>>> Could you please check KVM-PR on your PowerPC machine?
>>>>>
>>>>> Thanks,
>>>>> Christian
>>>>>
>>>>> [1] https://en.wikipedia.org/wiki/AmigaOne_X1000
>>>>
>>>> I figured out that the PowerPC updates 5.7-1 [1] are responsible for
>>>> the KVM-PR issue. Please test KVM-PR on your PowerPC machines and
>>>> check the PowerPC updates 5.7-1 [1].
>>>>
>>>> Thanks
>>>>
>>>> [1]
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969
>>>>
>>>>
>>> I tested the latest Git kernel with Mac-on-Linux/KVM-PR today.
>>> Unfortunately I can't use KVM-PR with MoL anymore because of this
>>> issue (see screenshots [1]). Please check the PowerPC updates 5.7-1.
>>>
>>> Thanks
>>>
>>> [1]
>>> -
>>> https://i.pinimg.com/originals/0c/b3/64/0cb364a40241fa2b7f297d4272bbb8b7.png
>>> -
>>> https://i.pinimg.com/originals/9a/61/d1/9a61d170b1c9f514f7a78a3014ffd18f.png
>>>
>> Hi All,
>>
>> I bisected today because of the KVM-PR issue.
>>
>> Result:
>>
>> 9600f261acaaabd476d7833cec2dd20f2919f1a0 is the first bad commit
>> commit 9600f261acaaabd476d7833cec2dd20f2919f1a0
>> Author: Nicholas Piggin <npiggin@gmail.com>
>> Date: Wed Feb 26 03:35:21 2020 +1000
>>
>> powerpc/64s/exception: Move KVM test to common code
>>
>> This allows more code to be moved out of unrelocated regions. The
>> system call KVMTEST is changed to be open-coded and remain in the
>> tramp area to avoid having to move it to entry_64.S. The custom
>> nature
>> of the system call entry code means the hcall case can be made more
>> streamlined than regular interrupt handlers.
>>
>> mpe: Incorporate fix from Nick:
>>
>> Moving KVM test to the common entry code missed the case of HMI and
>> MCE, which do not do __GEN_COMMON_ENTRY (because they don't want to
>> switch to virt mode).
>>
>> This means a MCE or HMI exception that is taken while KVM is
>> running a
>> guest context will not be switched out of that context, and KVM won't
>> be notified. Found by running sigfuz in guest with patched host on
>> POWER9 DD2.3, which causes some TM related HMI interrupts (which are
>> expected and supposed to be handled by KVM).
>>
>> This fix adds a __GEN_REALMODE_COMMON_ENTRY for those handlers to add
>> the KVM test. This makes them look a little more like other handlers
>> that all use __GEN_COMMON_ENTRY.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>> Link:
>> https://lore.kernel.org/r/20200225173541.1549955-13-npiggin@gmail.com
>>
>> :040000 040000 ec21cec22d165f8696d69532734cb2985d532cb0
>> 87dd49a9cd7202ec79350e8ca26cea01f1dbd93d M arch
>>
>> -----
>>
>> The following commit is the problem: powerpc/64s/exception: Move KVM
>> test to common code [1]
>>
>> These changes were included in the PowerPC updates 5.7-1. [2]
>>
>> Another test:
>>
>> git checkout d38c07afc356ddebaa3ed8ecb3f553340e05c969 (PowerPC updates
>> 5.7-1 [2] ) -> KVM-PR doesn't work.
>>
>> After that: git revert d38c07afc356ddebaa3ed8ecb3f553340e05c969 -m 1
>> -> KVM-PR works.
>>
>> Could you please check the first bad commit? [1]
>>
>> Thanks,
>> Christian
>>
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9600f261acaaabd476d7833cec2dd20f2919f1a0
>> [2]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969
>
> Hi All,
>
> I tried to revert the __GEN_REALMODE_COMMON_ENTRY fix for the latest Git
> kernel and for the stable kernel 5.7.2 but without any success. There
> was lot of restructuring work during the kernel 5.7 development time in
> the PowerPC area so it isn't possible reactivate the old code. That
> means we have lost the whole KVM-PR support. I also reported this issue
> to Alexander Graf two days ago. He wrote: "Howdy :). It looks pretty
> broken. Have you ever made a bisect to see where the problem comes from?"
>
> Please check the KVM-PR code.
Hey, thanks for debugging it and reporting. I'm looking into it, will
try to get a fix soon.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH] powerpc/64: indirect function call use bctrl rather than blrl in ret_from_kernel_thread
From: Nicholas Piggin @ 2020-06-14 9:24 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <1c6161a5-fa2f-9e19-a7f3-432bbfe3523b@csgroup.eu>
Excerpts from Christophe Leroy's message of June 11, 2020 10:26 pm:
>
>
> Le 11/06/2020 à 14:11, Nicholas Piggin a écrit :
>> blrl is not recommended to use as an indirect function call, as it may
>> corrupt the link stack predictor.
>>
>> This is not a performance critical path but this should be fixed for
>> consistency.
>
> There's exactly the same in entry_32.S
> Should it be changed there too ... for consistency :) ?
>
> ppc32 also uses blrl for calling syscall handler, should it be changed
> as well ?
Yes I would say so. I don't know much about 32-bit implementations but
MPC7450 at least has a link stack predictor.
Thanks,
Nick
^ permalink raw reply
* Re: Linux powerpc new system call instruction and ABI
From: Nicholas Piggin @ 2020-06-14 9:26 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: libc-dev, musl, linuxppc-dev, linux-api
In-Reply-To: <20200611210230.GH31009@gate.crashing.org>
Excerpts from Segher Boessenkool's message of June 12, 2020 7:02 am:
> Hi!
>
> On Thu, Jun 11, 2020 at 06:12:01PM +1000, Nicholas Piggin wrote:
>> Calling convention
>> ------------------
>> The proposal is for scv 0 to provide the standard Linux system call ABI
>> with the following differences from sc convention[1]:
>>
>> - lr is to be volatile across scv calls. This is necessary because the
>> scv instruction clobbers lr. From previous discussion, this should be
>> possible to deal with in GCC clobbers and CFI.
>>
>> - cr1 and cr5-cr7 are volatile. This matches the C ABI and would allow the
>> kernel system call exit to avoid restoring the volatile cr registers
>> (although we probably still would anyway to avoid information leaks).
>>
>> - Error handling: The consensus among kernel, glibc, and musl is to move to
>> using negative return values in r3 rather than CR0[SO]=1 to indicate error,
>> which matches most other architectures, and is closer to a function call.
>
> What about cr0 then? Will it be volatile as well (exactly like for
> function calls)?
Yes, same as for sc (except for SO bit). Which is a bit unclear in this
section.
>> Notes
>> -----
>> - r0,r4-r8 are documented as volatile in the ABI, but the kernel patch as
>> submitted currently preserves them. This is to leave room for deciding
>> which way to go with these.
>
> The kernel has to set it to *something* that doesn't leak information ;-)
For "sc" system calls these were defined as volatile (and used to just
leak information), so now we just zero them.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v2 1/4] powerpc/64s: implement probe_kernel_read/write without touching AMR
From: Nicholas Piggin @ 2020-06-14 9:28 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev
In-Reply-To: <bbee54ac-63d1-3638-dce8-6a2bee66623c@csgroup.eu>
Excerpts from Christophe Leroy's message of June 10, 2020 10:41 pm:
> Hi Nick
>
> Le 03/04/2020 à 11:35, Nicholas Piggin a écrit :
>> There is no need to allow user accesses when probing kernel addresses.
>
> You should have a look at
> https://github.com/torvalds/linux/commit/fa94111d94354de76c47fea6e1187d1ee91e23a7
>
> At seems to implement a generic way of achieving what you are trying to
> do here.
Yep thanks for that, I'll rebase this series on upstream now.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver
From: Chris Boot @ 2020-06-14 10:34 UTC (permalink / raw)
To: Finn Thain, Chris Boot
Cc: Bart Van Assche, linux-scsi, Chuhong Yuan, linux-kernel,
Nicholas Bellinger, target-devel, Martin K . Petersen,
linux1394-devel, linuxppc-dev, Stefan Richter
In-Reply-To: <alpine.LNX.2.22.394.2006140934520.15@nippy.intranet>
On 14/06/2020 01:03, Finn Thain wrote:
> On Sat, 13 Jun 2020, Chris Boot wrote:
>
>> I no longer have the time to maintain this subsystem nor the hardware to
>> test patches with.
>
> Then why not patch MAINTAINERS, and orphan it, as per usual practice?
>
> $ git log --oneline MAINTAINERS | grep -i orphan
My patch to remove it was in response to:
https://lore.kernel.org/lkml/yq1img99d4k.fsf@ca-mkp.ca.oracle.com/
>> It also doesn't appear to have any active users so I doubt anyone will
>> miss it.
>>
>
> It's not unusual that any Linux driver written more than 5 years ago
> "doesn't appear to have any active users".
>
> If a driver has been orphaned and broken in the past, and no-one stepped
> up to fix it within a reasonable period, removal would make sense. But
> that's not the case here.
>
> I haven't used this driver for a long time, but I still own PowerMacs with
> firewire, and I know I'm not the only one.
I expect that if someone finds this useful it can stick around (but
that's not my call). I just don't have the time or inclination or
hardware to be able to maintain it anymore, so someone else would have
to pick it up.
Cheers,
Chris
--
Chris Boot
bootc@boo.tc
^ permalink raw reply
* Re: PowerPC KVM-PR issue
From: Nicholas Piggin @ 2020-06-14 12:53 UTC (permalink / raw)
To: Christian Zigotzky, kvm-ppc@vger.kernel.org, linuxppc-dev
Cc: Darren Stevens, R.T.Dickinson, Christian Zigotzky
In-Reply-To: <fffeb817-35e0-2562-b3cf-2fd476948c76@xenosoft.de>
Excerpts from Christian Zigotzky's message of June 12, 2020 11:01 pm:
> On 11 June 2020 at 04:47 pm, Christian Zigotzky wrote:
>> On 10 June 2020 at 01:23 pm, Christian Zigotzky wrote:
>>> On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:
>>>> On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:
>>>>> Hello,
>>>>>
>>>>> KVM-PR doesn't work anymore on my Nemo board [1]. I figured out
>>>>> that the Git kernels and the kernel 5.7 are affected.
>>>>>
>>>>> Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at
>>>>> 700 failed (00000000)
>>>>>
>>>>> I can boot virtual QEMU PowerPC machines with KVM-PR with the
>>>>> kernel 5.6 without any problems on my Nemo board.
>>>>>
>>>>> I tested it with QEMU 2.5.0 and QEMU 5.0.0 today.
>>>>>
>>>>> Could you please check KVM-PR on your PowerPC machine?
>>>>>
>>>>> Thanks,
>>>>> Christian
>>>>>
>>>>> [1] https://en.wikipedia.org/wiki/AmigaOne_X1000
>>>>
>>>> I figured out that the PowerPC updates 5.7-1 [1] are responsible for
>>>> the KVM-PR issue. Please test KVM-PR on your PowerPC machines and
>>>> check the PowerPC updates 5.7-1 [1].
>>>>
>>>> Thanks
>>>>
>>>> [1]
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969
>>>>
>>>>
>>> I tested the latest Git kernel with Mac-on-Linux/KVM-PR today.
>>> Unfortunately I can't use KVM-PR with MoL anymore because of this
>>> issue (see screenshots [1]). Please check the PowerPC updates 5.7-1.
>>>
>>> Thanks
>>>
>>> [1]
>>> -
>>> https://i.pinimg.com/originals/0c/b3/64/0cb364a40241fa2b7f297d4272bbb8b7.png
>>> -
>>> https://i.pinimg.com/originals/9a/61/d1/9a61d170b1c9f514f7a78a3014ffd18f.png
>>>
>> Hi All,
>>
>> I bisected today because of the KVM-PR issue.
>>
>> Result:
>>
>> 9600f261acaaabd476d7833cec2dd20f2919f1a0 is the first bad commit
>> commit 9600f261acaaabd476d7833cec2dd20f2919f1a0
>> Author: Nicholas Piggin <npiggin@gmail.com>
>> Date: Wed Feb 26 03:35:21 2020 +1000
>>
>> powerpc/64s/exception: Move KVM test to common code
>>
>> This allows more code to be moved out of unrelocated regions. The
>> system call KVMTEST is changed to be open-coded and remain in the
>> tramp area to avoid having to move it to entry_64.S. The custom
>> nature
>> of the system call entry code means the hcall case can be made more
>> streamlined than regular interrupt handlers.
>>
>> mpe: Incorporate fix from Nick:
>>
>> Moving KVM test to the common entry code missed the case of HMI and
>> MCE, which do not do __GEN_COMMON_ENTRY (because they don't want to
>> switch to virt mode).
>>
>> This means a MCE or HMI exception that is taken while KVM is
>> running a
>> guest context will not be switched out of that context, and KVM won't
>> be notified. Found by running sigfuz in guest with patched host on
>> POWER9 DD2.3, which causes some TM related HMI interrupts (which are
>> expected and supposed to be handled by KVM).
>>
>> This fix adds a __GEN_REALMODE_COMMON_ENTRY for those handlers to add
>> the KVM test. This makes them look a little more like other handlers
>> that all use __GEN_COMMON_ENTRY.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>> Link:
>> https://lore.kernel.org/r/20200225173541.1549955-13-npiggin@gmail.com
>>
>> :040000 040000 ec21cec22d165f8696d69532734cb2985d532cb0
>> 87dd49a9cd7202ec79350e8ca26cea01f1dbd93d M arch
>>
>> -----
>>
>> The following commit is the problem: powerpc/64s/exception: Move KVM
>> test to common code [1]
>>
>> These changes were included in the PowerPC updates 5.7-1. [2]
>>
>> Another test:
>>
>> git checkout d38c07afc356ddebaa3ed8ecb3f553340e05c969 (PowerPC updates
>> 5.7-1 [2] ) -> KVM-PR doesn't work.
>>
>> After that: git revert d38c07afc356ddebaa3ed8ecb3f553340e05c969 -m 1
>> -> KVM-PR works.
>>
>> Could you please check the first bad commit? [1]
>>
>> Thanks,
>> Christian
>>
>>
>> [1]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9600f261acaaabd476d7833cec2dd20f2919f1a0
>> [2]
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969
>
> Hi All,
>
> I tried to revert the __GEN_REALMODE_COMMON_ENTRY fix for the latest Git
> kernel and for the stable kernel 5.7.2 but without any success. There
> was lot of restructuring work during the kernel 5.7 development time in
> the PowerPC area so it isn't possible reactivate the old code. That
> means we have lost the whole KVM-PR support. I also reported this issue
> to Alexander Graf two days ago. He wrote: "Howdy :). It looks pretty
> broken. Have you ever made a bisect to see where the problem comes from?"
>
> Please check the KVM-PR code.
Does this patch fix it for you?
The CTR register reload in the KVM interrupt path used the wrong save
area for SLB (and NMI) interrupts.
Fixes: 9600f261acaaa ("powerpc/64s/exception: Move KVM test to common code")
Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/exceptions-64s.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index e70ebb5c318c..fa080694e581 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -270,7 +270,7 @@ BEGIN_FTR_SECTION
END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
.endif
- ld r10,PACA_EXGEN+EX_CTR(r13)
+ ld r10,IAREA+EX_CTR(r13)
mtctr r10
BEGIN_FTR_SECTION
ld r10,IAREA+EX_PPR(r13)
@@ -298,7 +298,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
.if IKVM_SKIP
89: mtocrf 0x80,r9
- ld r10,PACA_EXGEN+EX_CTR(r13)
+ ld r10,IAREA+EX_CTR(r13)
mtctr r10
ld r9,IAREA+EX_R9(r13)
ld r10,IAREA+EX_R10(r13)
--
2.23.0
^ permalink raw reply related
* Re: PowerPC KVM-PR issue
From: Christian Zigotzky @ 2020-06-14 14:52 UTC (permalink / raw)
To: Nicholas Piggin, kvm-ppc@vger.kernel.org, linuxppc-dev
Cc: Darren Stevens, R.T.Dickinson, Christian Zigotzky
In-Reply-To: <1592139127.g2951cl0h6.astroid@bobo.none>
On 14 June 2020 at 02:53 pm, Nicholas Piggin wrote:
> Excerpts from Christian Zigotzky's message of June 12, 2020 11:01 pm:
>> On 11 June 2020 at 04:47 pm, Christian Zigotzky wrote:
>>> On 10 June 2020 at 01:23 pm, Christian Zigotzky wrote:
>>>> On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:
>>>>> On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:
>>>>>> Hello,
>>>>>>
>>>>>> KVM-PR doesn't work anymore on my Nemo board [1]. I figured out
>>>>>> that the Git kernels and the kernel 5.7 are affected.
>>>>>>
>>>>>> Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at
>>>>>> 700 failed (00000000)
>>>>>>
>>>>>> I can boot virtual QEMU PowerPC machines with KVM-PR with the
>>>>>> kernel 5.6 without any problems on my Nemo board.
>>>>>>
>>>>>> I tested it with QEMU 2.5.0 and QEMU 5.0.0 today.
>>>>>>
>>>>>> Could you please check KVM-PR on your PowerPC machine?
>>>>>>
>>>>>> Thanks,
>>>>>> Christian
>>>>>>
>>>>>> [1] https://en.wikipedia.org/wiki/AmigaOne_X1000
>>>>> I figured out that the PowerPC updates 5.7-1 [1] are responsible for
>>>>> the KVM-PR issue. Please test KVM-PR on your PowerPC machines and
>>>>> check the PowerPC updates 5.7-1 [1].
>>>>>
>>>>> Thanks
>>>>>
>>>>> [1]
>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969
>>>>>
>>>>>
>>>> I tested the latest Git kernel with Mac-on-Linux/KVM-PR today.
>>>> Unfortunately I can't use KVM-PR with MoL anymore because of this
>>>> issue (see screenshots [1]). Please check the PowerPC updates 5.7-1.
>>>>
>>>> Thanks
>>>>
>>>> [1]
>>>> -
>>>> https://i.pinimg.com/originals/0c/b3/64/0cb364a40241fa2b7f297d4272bbb8b7.png
>>>> -
>>>> https://i.pinimg.com/originals/9a/61/d1/9a61d170b1c9f514f7a78a3014ffd18f.png
>>>>
>>> Hi All,
>>>
>>> I bisected today because of the KVM-PR issue.
>>>
>>> Result:
>>>
>>> 9600f261acaaabd476d7833cec2dd20f2919f1a0 is the first bad commit
>>> commit 9600f261acaaabd476d7833cec2dd20f2919f1a0
>>> Author: Nicholas Piggin <npiggin@gmail.com>
>>> Date: Wed Feb 26 03:35:21 2020 +1000
>>>
>>> powerpc/64s/exception: Move KVM test to common code
>>>
>>> This allows more code to be moved out of unrelocated regions. The
>>> system call KVMTEST is changed to be open-coded and remain in the
>>> tramp area to avoid having to move it to entry_64.S. The custom
>>> nature
>>> of the system call entry code means the hcall case can be made more
>>> streamlined than regular interrupt handlers.
>>>
>>> mpe: Incorporate fix from Nick:
>>>
>>> Moving KVM test to the common entry code missed the case of HMI and
>>> MCE, which do not do __GEN_COMMON_ENTRY (because they don't want to
>>> switch to virt mode).
>>>
>>> This means a MCE or HMI exception that is taken while KVM is
>>> running a
>>> guest context will not be switched out of that context, and KVM won't
>>> be notified. Found by running sigfuz in guest with patched host on
>>> POWER9 DD2.3, which causes some TM related HMI interrupts (which are
>>> expected and supposed to be handled by KVM).
>>>
>>> This fix adds a __GEN_REALMODE_COMMON_ENTRY for those handlers to add
>>> the KVM test. This makes them look a little more like other handlers
>>> that all use __GEN_COMMON_ENTRY.
>>>
>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>>> Link:
>>> https://lore.kernel.org/r/20200225173541.1549955-13-npiggin@gmail.com
>>>
>>> :040000 040000 ec21cec22d165f8696d69532734cb2985d532cb0
>>> 87dd49a9cd7202ec79350e8ca26cea01f1dbd93d M arch
>>>
>>> -----
>>>
>>> The following commit is the problem: powerpc/64s/exception: Move KVM
>>> test to common code [1]
>>>
>>> These changes were included in the PowerPC updates 5.7-1. [2]
>>>
>>> Another test:
>>>
>>> git checkout d38c07afc356ddebaa3ed8ecb3f553340e05c969 (PowerPC updates
>>> 5.7-1 [2] ) -> KVM-PR doesn't work.
>>>
>>> After that: git revert d38c07afc356ddebaa3ed8ecb3f553340e05c969 -m 1
>>> -> KVM-PR works.
>>>
>>> Could you please check the first bad commit? [1]
>>>
>>> Thanks,
>>> Christian
>>>
>>>
>>> [1]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9600f261acaaabd476d7833cec2dd20f2919f1a0
>>> [2]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969
>> Hi All,
>>
>> I tried to revert the __GEN_REALMODE_COMMON_ENTRY fix for the latest Git
>> kernel and for the stable kernel 5.7.2 but without any success. There
>> was lot of restructuring work during the kernel 5.7 development time in
>> the PowerPC area so it isn't possible reactivate the old code. That
>> means we have lost the whole KVM-PR support. I also reported this issue
>> to Alexander Graf two days ago. He wrote: "Howdy :). It looks pretty
>> broken. Have you ever made a bisect to see where the problem comes from?"
>>
>> Please check the KVM-PR code.
> Does this patch fix it for you?
>
> The CTR register reload in the KVM interrupt path used the wrong save
> area for SLB (and NMI) interrupts.
>
> Fixes: 9600f261acaaa ("powerpc/64s/exception: Move KVM test to common code")
> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/kernel/exceptions-64s.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index e70ebb5c318c..fa080694e581 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -270,7 +270,7 @@ BEGIN_FTR_SECTION
> END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
> .endif
>
> - ld r10,PACA_EXGEN+EX_CTR(r13)
> + ld r10,IAREA+EX_CTR(r13)
> mtctr r10
> BEGIN_FTR_SECTION
> ld r10,IAREA+EX_PPR(r13)
> @@ -298,7 +298,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
>
> .if IKVM_SKIP
> 89: mtocrf 0x80,r9
> - ld r10,PACA_EXGEN+EX_CTR(r13)
> + ld r10,IAREA+EX_CTR(r13)
> mtctr r10
> ld r9,IAREA+EX_R9(r13)
> ld r10,IAREA+EX_R10(r13)
Many thanks for the fix! I will test it with the RC1 tomorrow.
-- Christian
^ permalink raw reply
* [PATCH] SUNRPC: Add missing asm/cacheflush.h
From: Christophe Leroy @ 2020-06-14 17:07 UTC (permalink / raw)
To: Chuck Lever, J. Bruce Fields, Trond Myklebust, Anna Schumaker,
David S. Miller, Jakub Kicinski
Cc: netdev, linux-nfs, linuxppc-dev, linux-kernel
Even if that's only a warning, not including asm/cacheflush.h
leads to svc_flush_bvec() being empty allthough powerpc defines
ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE.
CC net/sunrpc/svcsock.o
net/sunrpc/svcsock.c:227:5: warning: "ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE" is not defined [-Wundef]
#if ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE
^
Fixes: ca07eda33e01 ("SUNRPC: Refactor svc_recvfrom()")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
I detected this on linux-next on June 4th and warned Chuck. Seems like it went into mainline anyway.
net/sunrpc/svcsock.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 5c4ec9386f81..d9e99cb09aab 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -45,6 +45,7 @@
#include <net/tcp_states.h>
#include <linux/uaccess.h>
#include <asm/ioctls.h>
+#include <asm/cacheflush.h>
#include <linux/sunrpc/types.h>
#include <linux/sunrpc/clnt.h>
--
2.25.0
^ permalink raw reply related
* Re: [PATCH] SUNRPC: Add missing asm/cacheflush.h
From: Chuck Lever @ 2020-06-14 18:57 UTC (permalink / raw)
To: Christophe Leroy
Cc: Linux NFS Mailing List, netdev, Linux Kernel Mailing List,
Trond Myklebust, Bruce Fields, Anna Schumaker, Jakub Kicinski,
linuxppc-dev, David S. Miller
In-Reply-To: <a356625c9aa1b5d711e320c39779e0c713f204cb.1592154127.git.christophe.leroy@csgroup.eu>
Hi Christophe -
> On Jun 14, 2020, at 1:07 PM, Christophe Leroy <christophe.leroy@csgroup.eu> wrote:
>
> Even if that's only a warning, not including asm/cacheflush.h
> leads to svc_flush_bvec() being empty allthough powerpc defines
> ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE.
>
> CC net/sunrpc/svcsock.o
> net/sunrpc/svcsock.c:227:5: warning: "ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE" is not defined [-Wundef]
> #if ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE
> ^
>
> Fixes: ca07eda33e01 ("SUNRPC: Refactor svc_recvfrom()")
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> I detected this on linux-next on June 4th and warned Chuck. Seems like it went into mainline anyway.
Thanks for your patch. I've searched my mailbox. It appears I never
received your June 4th e-mail.
Does your patch also address:
https://marc.info/?l=linux-kernel&m=159194369128024&w=2 ?
If so, then
Reported-by: kernel test robot <lkp@intel.com>
should be added to the patch description.
Ideally, compilation on x86_64 should have thrown the same warning,
but it didn't. Why would the x86_64 build behave differently than
ppc64 or i386?
> net/sunrpc/svcsock.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> index 5c4ec9386f81..d9e99cb09aab 100644
> --- a/net/sunrpc/svcsock.c
> +++ b/net/sunrpc/svcsock.c
> @@ -45,6 +45,7 @@
> #include <net/tcp_states.h>
> #include <linux/uaccess.h>
> #include <asm/ioctls.h>
> +#include <asm/cacheflush.h>
Nit: Let's include <linux/highmem.h> in net/sunrpc/svcsock.h instead
of <asm/cacheflush.h> directly.
> #include <linux/sunrpc/types.h>
> #include <linux/sunrpc/clnt.h>
> --
> 2.25.0
>
--
Chuck Lever
^ permalink raw reply
* Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver
From: Finn Thain @ 2020-06-14 23:28 UTC (permalink / raw)
To: Chris Boot
Cc: Chris Boot, Bart Van Assche, linux-scsi, Chuhong Yuan,
linux-kernel, Nicholas Bellinger, target-devel,
Martin K . Petersen, linux1394-devel, linuxppc-dev,
Stefan Richter
In-Reply-To: <7ad14946-5c25-fc49-1e48-72d37a607832@boo.tc>
On Sun, 14 Jun 2020, Chris Boot wrote:
> I expect that if someone finds this useful it can stick around (but
> that's not my call).
Who's call is that? If the patch had said "From: Martin K. Petersen" and
"This driver is being removed because it has the following defects..."
that would be some indication of a good-faith willingness to accept users
as developers in the spirit of the GPL, which is what you seem to be
alluding to (?).
> I just don't have the time or inclination or hardware to be able to
> maintain it anymore, so someone else would have to pick it up.
>
Which is why most drivers get orphaned, right?
^ permalink raw reply
* [PATCH v2] powerpc/powernv/pci: use ifdef to avoid dead code
From: Greg Thelen @ 2020-06-14 23:32 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Oliver O'Halloran
Cc: Greg Thelen, linuxppc-dev, linux-kernel
In-Reply-To: <37af499e-2b8b-7e78-ed4b-0aaf711fcb38@csgroup.eu>
Commit dc3d8f85bb57 ("powerpc/powernv/pci: Re-work bus PE
configuration") removed a couple pnv_ioda_setup_bus_dma() calls. The
only remaining calls are behind CONFIG_IOMMU_API. Thus builds without
CONFIG_IOMMU_API see:
arch/powerpc/platforms/powernv/pci-ioda.c:1888:13: error: 'pnv_ioda_setup_bus_dma' defined but not used
Move pnv_ioda_setup_bus_dma() under CONFIG_IOMMU_API to avoid dead code.
Fixes: dc3d8f85bb57 ("powerpc/powernv/pci: Re-work bus PE configuration")
Signed-off-by: Greg Thelen <gthelen@google.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 26 +++++++++++------------
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 73a63efcf855..743d840712da 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1885,19 +1885,6 @@ static bool pnv_pci_ioda_iommu_bypass_supported(struct pci_dev *pdev,
return false;
}
-static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
-{
- struct pci_dev *dev;
-
- list_for_each_entry(dev, &bus->devices, bus_list) {
- set_iommu_table_base(&dev->dev, pe->table_group.tables[0]);
- dev->dev.archdata.dma_offset = pe->tce_bypass_base;
-
- if ((pe->flags & PNV_IODA_PE_BUS_ALL) && dev->subordinate)
- pnv_ioda_setup_bus_dma(pe, dev->subordinate);
- }
-}
-
static inline __be64 __iomem *pnv_ioda_get_inval_reg(struct pnv_phb *phb,
bool real_mode)
{
@@ -2501,6 +2488,19 @@ static long pnv_pci_ioda2_unset_window(struct iommu_table_group *table_group,
#endif
#ifdef CONFIG_IOMMU_API
+static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe, struct pci_bus *bus)
+{
+ struct pci_dev *dev;
+
+ list_for_each_entry(dev, &bus->devices, bus_list) {
+ set_iommu_table_base(&dev->dev, pe->table_group.tables[0]);
+ dev->dev.archdata.dma_offset = pe->tce_bypass_base;
+
+ if ((pe->flags & PNV_IODA_PE_BUS_ALL) && dev->subordinate)
+ pnv_ioda_setup_bus_dma(pe, dev->subordinate);
+ }
+}
+
unsigned long pnv_pci_ioda2_get_table_size(__u32 page_shift,
__u64 window_size, __u32 levels)
{
--
2.27.0.290.gba653c62da-goog
^ permalink raw reply related
* Re: PowerPC KVM-PR issue
From: Christian Zigotzky @ 2020-06-14 23:39 UTC (permalink / raw)
To: Nicholas Piggin, kvm-ppc@vger.kernel.org, linuxppc-dev
Cc: Darren Stevens, R.T.Dickinson, Christian Zigotzky
In-Reply-To: <e253e916-7f50-f1df-fed1-57d14baa38e6@xenosoft.de>
On 14 June 2020 at 04:52 pm, Christian Zigotzky wrote:
> On 14 June 2020 at 02:53 pm, Nicholas Piggin wrote:
>> Excerpts from Christian Zigotzky's message of June 12, 2020 11:01 pm:
>>> On 11 June 2020 at 04:47 pm, Christian Zigotzky wrote:
>>>> On 10 June 2020 at 01:23 pm, Christian Zigotzky wrote:
>>>>> On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:
>>>>>> On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> KVM-PR doesn't work anymore on my Nemo board [1]. I figured out
>>>>>>> that the Git kernels and the kernel 5.7 are affected.
>>>>>>>
>>>>>>> Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at
>>>>>>> 700 failed (00000000)
>>>>>>>
>>>>>>> I can boot virtual QEMU PowerPC machines with KVM-PR with the
>>>>>>> kernel 5.6 without any problems on my Nemo board.
>>>>>>>
>>>>>>> I tested it with QEMU 2.5.0 and QEMU 5.0.0 today.
>>>>>>>
>>>>>>> Could you please check KVM-PR on your PowerPC machine?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Christian
>>>>>>>
>>>>>>> [1] https://en.wikipedia.org/wiki/AmigaOne_X1000
>>>>>> I figured out that the PowerPC updates 5.7-1 [1] are responsible for
>>>>>> the KVM-PR issue. Please test KVM-PR on your PowerPC machines and
>>>>>> check the PowerPC updates 5.7-1 [1].
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> [1]
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969
>>>>>>
>>>>>>
>>>>>>
>>>>> I tested the latest Git kernel with Mac-on-Linux/KVM-PR today.
>>>>> Unfortunately I can't use KVM-PR with MoL anymore because of this
>>>>> issue (see screenshots [1]). Please check the PowerPC updates 5.7-1.
>>>>>
>>>>> Thanks
>>>>>
>>>>> [1]
>>>>> -
>>>>> https://i.pinimg.com/originals/0c/b3/64/0cb364a40241fa2b7f297d4272bbb8b7.png
>>>>>
>>>>> -
>>>>> https://i.pinimg.com/originals/9a/61/d1/9a61d170b1c9f514f7a78a3014ffd18f.png
>>>>>
>>>>>
>>>> Hi All,
>>>>
>>>> I bisected today because of the KVM-PR issue.
>>>>
>>>> Result:
>>>>
>>>> 9600f261acaaabd476d7833cec2dd20f2919f1a0 is the first bad commit
>>>> commit 9600f261acaaabd476d7833cec2dd20f2919f1a0
>>>> Author: Nicholas Piggin <npiggin@gmail.com>
>>>> Date: Wed Feb 26 03:35:21 2020 +1000
>>>>
>>>> powerpc/64s/exception: Move KVM test to common code
>>>>
>>>> This allows more code to be moved out of unrelocated regions. The
>>>> system call KVMTEST is changed to be open-coded and remain in the
>>>> tramp area to avoid having to move it to entry_64.S. The custom
>>>> nature
>>>> of the system call entry code means the hcall case can be made
>>>> more
>>>> streamlined than regular interrupt handlers.
>>>>
>>>> mpe: Incorporate fix from Nick:
>>>>
>>>> Moving KVM test to the common entry code missed the case of
>>>> HMI and
>>>> MCE, which do not do __GEN_COMMON_ENTRY (because they don't
>>>> want to
>>>> switch to virt mode).
>>>>
>>>> This means a MCE or HMI exception that is taken while KVM is
>>>> running a
>>>> guest context will not be switched out of that context, and
>>>> KVM won't
>>>> be notified. Found by running sigfuz in guest with patched
>>>> host on
>>>> POWER9 DD2.3, which causes some TM related HMI interrupts
>>>> (which are
>>>> expected and supposed to be handled by KVM).
>>>>
>>>> This fix adds a __GEN_REALMODE_COMMON_ENTRY for those handlers
>>>> to add
>>>> the KVM test. This makes them look a little more like other
>>>> handlers
>>>> that all use __GEN_COMMON_ENTRY.
>>>>
>>>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>>>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
>>>> Link:
>>>> https://lore.kernel.org/r/20200225173541.1549955-13-npiggin@gmail.com
>>>>
>>>> :040000 040000 ec21cec22d165f8696d69532734cb2985d532cb0
>>>> 87dd49a9cd7202ec79350e8ca26cea01f1dbd93d M arch
>>>>
>>>> -----
>>>>
>>>> The following commit is the problem: powerpc/64s/exception: Move KVM
>>>> test to common code [1]
>>>>
>>>> These changes were included in the PowerPC updates 5.7-1. [2]
>>>>
>>>> Another test:
>>>>
>>>> git checkout d38c07afc356ddebaa3ed8ecb3f553340e05c969 (PowerPC updates
>>>> 5.7-1 [2] ) -> KVM-PR doesn't work.
>>>>
>>>> After that: git revert d38c07afc356ddebaa3ed8ecb3f553340e05c969 -m 1
>>>> -> KVM-PR works.
>>>>
>>>> Could you please check the first bad commit? [1]
>>>>
>>>> Thanks,
>>>> Christian
>>>>
>>>>
>>>> [1]
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9600f261acaaabd476d7833cec2dd20f2919f1a0
>>>>
>>>> [2]
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969
>>>>
>>> Hi All,
>>>
>>> I tried to revert the __GEN_REALMODE_COMMON_ENTRY fix for the latest
>>> Git
>>> kernel and for the stable kernel 5.7.2 but without any success. There
>>> was lot of restructuring work during the kernel 5.7 development time in
>>> the PowerPC area so it isn't possible reactivate the old code. That
>>> means we have lost the whole KVM-PR support. I also reported this issue
>>> to Alexander Graf two days ago. He wrote: "Howdy :). It looks pretty
>>> broken. Have you ever made a bisect to see where the problem comes
>>> from?"
>>>
>>> Please check the KVM-PR code.
>> Does this patch fix it for you?
>>
>> The CTR register reload in the KVM interrupt path used the wrong save
>> area for SLB (and NMI) interrupts.
>>
>> Fixes: 9600f261acaaa ("powerpc/64s/exception: Move KVM test to common
>> code")
>> Reported-by: Christian Zigotzky <chzigotzky@xenosoft.de>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/kernel/exceptions-64s.S | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/exceptions-64s.S
>> b/arch/powerpc/kernel/exceptions-64s.S
>> index e70ebb5c318c..fa080694e581 100644
>> --- a/arch/powerpc/kernel/exceptions-64s.S
>> +++ b/arch/powerpc/kernel/exceptions-64s.S
>> @@ -270,7 +270,7 @@ BEGIN_FTR_SECTION
>> END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
>> .endif
>> - ld r10,PACA_EXGEN+EX_CTR(r13)
>> + ld r10,IAREA+EX_CTR(r13)
>> mtctr r10
>> BEGIN_FTR_SECTION
>> ld r10,IAREA+EX_PPR(r13)
>> @@ -298,7 +298,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
>> .if IKVM_SKIP
>> 89: mtocrf 0x80,r9
>> - ld r10,PACA_EXGEN+EX_CTR(r13)
>> + ld r10,IAREA+EX_CTR(r13)
>> mtctr r10
>> ld r9,IAREA+EX_R9(r13)
>> ld r10,IAREA+EX_R10(r13)
> Many thanks for the fix! I will test it with the RC1 tomorrow.
>
> -- Christian
It works! :-) Thanks a lot! Screenshot:
https://i.pinimg.com/originals/5d/5f/e5/5d5fe584db474dc88bcc641450b2a7e0.png
-- Christian
^ permalink raw reply
* Re: [PATCH] powerpc/fsl_booke/32: fix build with CONFIG_RANDOMIZE_BASE
From: Jason Yan @ 2020-06-15 1:19 UTC (permalink / raw)
To: Arseny Solokha, Michael Ellerman, linuxppc-dev
Cc: Scott Wood, Christophe Leroy, linux-kernel, stable
In-Reply-To: <20200613162801.1946619-1-asolokha@kb.kras.ru>
在 2020/6/14 0:28, Arseny Solokha 写道:
> Building the current 5.8 kernel for a e500 machine with
> CONFIG_RANDOMIZE_BASE set yields the following failure:
>
> arch/powerpc/mm/nohash/kaslr_booke.c: In function 'kaslr_early_init':
> arch/powerpc/mm/nohash/kaslr_booke.c:387:2: error: implicit declaration
> of function 'flush_icache_range'; did you mean 'flush_tlb_range'?
> [-Werror=implicit-function-declaration]
>
> Indeed, including asm/cacheflush.h into kaslr_booke.c fixes the build.
>
> The issue dates back to the introduction of that file and probably went
> unnoticed because there's no in-tree defconfig with CONFIG_RANDOMIZE_BASE
> set.
>
> Fixes: 2b0e86cc5de6 ("powerpc/fsl_booke/32: implement KASLR infrastructure")
> Cc: stable@vger.kernel.org
> Signed-off-by: Arseny Solokha <asolokha@kb.kras.ru>
> ---
> arch/powerpc/mm/nohash/kaslr_booke.c | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Jason Yan <yanaijie@huawei.com>
^ permalink raw reply
* Re: [PATCH v2] powerpc/powernv/pci: use ifdef to avoid dead code
From: Oliver O'Halloran @ 2020-06-15 1:40 UTC (permalink / raw)
To: Greg Thelen; +Cc: Linux Kernel Mailing List, Paul Mackerras, linuxppc-dev
In-Reply-To: <20200614233235.121432-1-gthelen@google.com>
On Mon, Jun 15, 2020 at 9:33 AM Greg Thelen <gthelen@google.com> wrote:
>
> Commit dc3d8f85bb57 ("powerpc/powernv/pci: Re-work bus PE
> configuration") removed a couple pnv_ioda_setup_bus_dma() calls. The
> only remaining calls are behind CONFIG_IOMMU_API. Thus builds without
> CONFIG_IOMMU_API see:
> arch/powerpc/platforms/powernv/pci-ioda.c:1888:13: error: 'pnv_ioda_setup_bus_dma' defined but not used
>
> Move pnv_ioda_setup_bus_dma() under CONFIG_IOMMU_API to avoid dead code.
Doh! Thanks for the fix.
Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
^ 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