Re: [PATCH] scsi: target/sbp: remove firewire SBP target driver
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 > --- > 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 >
Re: [PATCH] powerpc/fsl_booke/32: fix build with CONFIG_RANDOMIZE_BASE
> 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
#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: sta...@vger.kernel.org
>> Signed-off-by: Arseny Solokha
>> ---
>> 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
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>>
[PATCH] powerpc/fsl_booke/32: fix build with CONFIG_RANDOMIZE_BASE
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: sta...@vger.kernel.org
Signed-off-by: Arseny Solokha
---
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
#include
#include
+#include
#include
#include
#include
--
2.27.0
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.8-2 tag
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
Re: [PATCH] powerpc/fsl_booke/32: fix build with CONFIG_RANDOMIZE_BASE
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: sta...@vger.kernel.org
Signed-off-by: Arseny Solokha
---
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
#include
#include
+#include
#include
#include
#include
[GIT PULL] Please pull powerpc/linux.git powerpc-5.8-2 tag
-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-
Re: [PATCH v2 11/12] x86/mmu: Allocate/free PASID
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
Reviewed-by: Tony Luck
---
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
#include
#include
+#include
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,
Re: [PATCH v2 04/12] docs: x86: Add documentation for SVA (Shared Virtual Addressing)
Hi Fenghua, On 2020/6/13 8:41, Fenghua Yu wrote: From: Ashok Raj 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 Co-developed-by: Fenghua Yu Signed-off-by: Fenghua Yu Reviewed-by: Tony Luck --- 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 ..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 in
Re: [PATCH v4 1/2] powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'
Nick Desaulniers writes: > On Thu, Jun 11, 2020 at 4:53 PM Segher Boessenkool > wrote: >> >> On Thu, Jun 11, 2020 at 03:43:55PM -0700, Nick Desaulniers wrote: >> > Segher, Cristophe, I suspect Clang is missing support for the %L and %U >> > output templates [1]. ... > > IIUC the bug report correctly, it looks like LLVM is failing for the > __put_user_asm2_goto case for -m32. A simple reproducer: > https://godbolt.org/z/jBBF9b If you add `-mregnames` you get register names: https://godbolt.org/z/MxLjhF foo: stw %r3, 0(%r5) stw %r4, 4(%r5) blr cheers
