Re: [PATCH v2 0/5] ibmvfc: MQ preparatory locking work
Tyrel, > The ibmvfc driver in its current form relies heavily on the > host_lock. This patchset introduces a genric queue with its own queue > lock and sent/free event list locks. This generic queue allows the > driver to decouple the primary queue and future subordinate queues > from the host lock reducing lock contention while also relaxing > locking for submissions and completions to simply the list lock of the > queue in question. Applied to 5.12/scsi-staging, thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH] ibmvfc: fix missing cast of ibmvfc_event pointer to u64 handle
On Wed, 6 Jan 2021 14:37:21 -0600, Tyrel Datwyler wrote:
> Commit 2aa0102c6688 ("scsi: ibmvfc: Use correlation token to tag
> commands") sets the vfcFrame correlation token to the pointer handle of
> the associated ibmvfc_event. However, that commit failed to cast the
> pointer to an appropriate type which in this case is a u64. As such
> sparse warnings are generated for both correlation token assignments.
>
> ibmvfc.c:2375:36: sparse: incorrect type in argument 1 (different base types)
> ibmvfc.c:2375:36: sparse: expected unsigned long long [usertype] val
> ibmvfc.c:2375:36: sparse: got struct ibmvfc_event *[assigned] evt
>
> [...]
Applied to 5.11/scsi-fixes, thanks!
[1/1] ibmvfc: fix missing cast of ibmvfc_event pointer to u64 handle
https://git.kernel.org/mkp/scsi/c/901d01c8e50c
--
Martin K. Petersen Oracle Linux Engineering
Re: [RFC PATCH v3 5/6] dt-bindings: of: Add restricted DMA pool
On Fri, Jan 08, 2021 at 01:39:43AM +0800, Claire Chang wrote: > On Thu, Jan 7, 2021 at 2:58 AM Konrad Rzeszutek Wilk > wrote: > > > > On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote: > > > Introduce the new compatible string, restricted-dma-pool, for restricted > > > DMA. One can specify the address and length of the restricted DMA memory > > > region by restricted-dma-pool in the device tree. > > > > > > Signed-off-by: Claire Chang > > > --- > > > .../reserved-memory/reserved-memory.txt | 24 +++ > > > 1 file changed, 24 insertions(+) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > > b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > > index e8d3096d922c..44975e2a1fd2 100644 > > > --- > > > a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > > +++ > > > b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > > @@ -51,6 +51,20 @@ compatible (optional) - standard definition > > >used as a shared pool of DMA buffers for a set of devices. It > > > can > > >be used by an operating system to instantiate the necessary > > > pool > > >management subsystem if necessary. > > > +- restricted-dma-pool: This indicates a region of memory meant > > > to be > > > + used as a pool of restricted DMA buffers for a set of devices. > > > The > > > + memory region would be the only region accessible to those > > > devices. > > > + When using this, the no-map and reusable properties must not > > > be set, > > > + so the operating system can create a virtual mapping that will > > > be used > > > + for synchronization. The main purpose for restricted DMA is to > > > + mitigate the lack of DMA access control on systems without an > > > IOMMU, > > > + which could result in the DMA accessing the system memory at > > > + unexpected times and/or unexpected addresses, possibly leading > > > to data > > > + leakage or corruption. The feature on its own provides a basic > > > level > > > + of protection against the DMA overwriting buffer contents at > > > + unexpected times. However, to protect against general data > > > leakage and > > > + system memory corruption, the system needs to provide way to > > > restrict > > > + the DMA to a predefined memory region. > > > > Heya! > > > > I think I am missing something obvious here so please bear with my > > questions: > > > > - This code adds the means of having the SWIOTLB pool tied to a specific > >memory correct? > > It doesn't affect the existing SWIOTLB. It just utilizes the existing SWIOTLB > code to create another DMA pool tied to a specific memory region for a given > set > of devices. It bounces the streaming DMA (map/unmap) in and out of that region > and does the memory allocation (dma_direct_alloc) from the same region. Right, so why can't it follow the same mechanism that Xen SWIOTLB does - which had exactly the same problem (needed special handling on the pool) - and do a similar code? > > > > > > > - Nothing stops the physical device from bypassing the SWIOTLB buffer. > >That is if an errant device screwed up the length or DMA address, the > >SWIOTLB would gladly do what the device told it do? > > So the system needs to provide a way to lock down the memory access, e.g. MPU. OK! Would it be prudent to have this in the description above perhaps? > > > > > - This has to be combined with SWIOTLB-force-ish to always use the > >bounce buffer, otherwise you could still do DMA without using > >SWIOTLB (by not hitting the criteria for needing to use SWIOTLB)? > > Since restricted DMA is for the devices that are not behind an IOMMU, I change > the criteria > `if (unlikely(swiotlb_force == SWIOTLB_FORCE))` > to > `if (unlikely(swiotlb_force == SWIOTLB_FORCE) || dev->dma_io_tlb_mem)` > in dma_direct_map_page(). > > Also, even if SWIOTLB=force, the restricted DMA pool is preferred if available > (get_io_tlb_mem in https://lore.kernel.org/patchwork/patch/1360995/). > > Thanks!
Re: [RFC PATCH v3 0/6] Restricted DMA
On Thu, Jan 7, 2021 at 2:48 AM Florian Fainelli wrote: > > Hi, > > First of all let me say that I am glad that someone is working on a > upstream solution for this issue, would appreciate if you could CC and > Jim Quinlan on subsequent submissions. Sure! > > > On 1/5/21 7:41 PM, Claire Chang wrote: > > This series implements mitigations for lack of DMA access control on > > systems without an IOMMU, which could result in the DMA accessing the > > system memory at unexpected times and/or unexpected addresses, possibly > > leading to data leakage or corruption. > > > > For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is > > not behind an IOMMU. As PCI-e, by design, gives the device full access to > > system memory, a vulnerability in the Wi-Fi firmware could easily escalate > > to a full system exploit (remote wifi exploits: [1a], [1b] that shows a > > full chain of exploits; [2], [3]). > > > > To mitigate the security concerns, we introduce restricted DMA. Restricted > > DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a > > specially allocated region and does memory allocation from the same region. > > The feature on its own provides a basic level of protection against the DMA > > overwriting buffer contents at unexpected times. However, to protect > > against general data leakage and system memory corruption, the system needs > > to provide a way to restrict the DMA to a predefined memory region (this is > > usually done at firmware level, e.g. in ATF on some ARM platforms). > > Can you explain how ATF gets involved and to what extent it does help, > besides enforcing a secure region from the ARM CPU's perpsective? Does > the PCIe root complex not have an IOMMU but can somehow be denied access > to a region that is marked NS=0 in the ARM CPU's MMU? If so, that is > still some sort of basic protection that the HW enforces, right? We need the ATF support for memory MPU (memory protection unit). Restricted DMA (with reserved-memory in dts) makes sure the predefined memory region is for PCIe DMA only, but we still need MPU to locks down PCIe access to that specific regions. > > On Broadcom STB SoCs we have had something similar for a while however > and while we don't have an IOMMU for the PCIe bridge, we do have a a > basic protection mechanism whereby we can configure a region in DRAM to > be PCIe read/write and CPU read/write which then gets used as the PCIe > inbound region for the PCIe EP. By default the PCIe bridge is not > allowed access to DRAM so we must call into a security agent to allow > the PCIe bridge to access the designated DRAM region. > > We have done this using a private CMA area region assigned via Device > Tree, assigned with a and requiring the PCIe EP driver to use > dma_alloc_from_contiguous() in order to allocate from this device > private CMA area. The only drawback with that approach is that it > requires knowing how much memory you need up front for buffers and DMA > descriptors that the PCIe EP will need to process. The problem is that > it requires driver modifications and that does not scale over the number > of PCIe EP drivers, some we absolutely do not control, but there is no > need to bounce buffer. Your approach scales better across PCIe EP > drivers however it does require bounce buffering which could be a > performance hit. Only the streaming DMA (map/unmap) needs bounce buffering. I also added alloc/free support in this series (https://lore.kernel.org/patchwork/patch/1360995/), so dma_direct_alloc() will try to allocate memory from the predefined memory region. As for the performance hit, it should be similar to the default swiotlb. Here are my experiment results. Both SoCs lack IOMMU for PCIe. PCIe wifi vht80 throughput - MTK SoC tcp_tx tcp_rxudp_tx udp_rx w/o Restricted DMA 244.1 134.66 312.56 350.79 w/ Restricted DMA246.95 136.59 363.21 351.99 Rockchip SoC tcp_tx tcp_rxudp_tx udp_rx w/o Restricted DMA 237.87 133.86 288.28 361.88 w/ Restricted DMA256.01 130.95 292.28 353.19 The CPU usage doesn't increase too much either. Although I didn't measure the CPU usage very precisely, it's ~3% with a single big core (Cortex-A72) and ~5% with a single small core (Cortex-A53). Thanks! > > Thanks! On Thu, Jan 7, 2021 at 2:48 AM Florian Fainelli wrote: > Hi, > > First of all let me say that I am glad that someone is working on a > upstream solution for this issue, would appreciate if you could CC and > Jim Quinlan on subsequent submissions. > > On 1/5/21 7:41 PM, Claire Chang wrote: > > This series implements mitigations for lack of DMA access control on > > systems without an IOMMU, which could result in the DMA accessing the > > system memory at unexpected times and/or unexpected addresses, possibly > > leading to data leakage or corruption. > > > > For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is > >
Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool
On Thu, Jan 07, 2021 at 10:09:14AM -0800, Florian Fainelli wrote: > On 1/7/21 9:57 AM, Konrad Rzeszutek Wilk wrote: > > On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote: > >> Hi Greg and Konrad, > >> > >> This change is intended to be non-arch specific. Any arch that lacks DMA > >> access > >> control and has devices not behind an IOMMU can make use of it. Could you > >> share > >> why you think this should be arch specific? > > > > The idea behind non-arch specific code is it to be generic. The devicetree > > is specific to PowerPC, Sparc, and ARM, and not to x86 - hence it should > > be in arch specific code. > > In premise the same code could be used with an ACPI enabled system with > an appropriate service to identify the restricted DMA regions and unlock > them. Which this patchset is not. > > More than 1 architecture requiring this function (ARM and ARM64 are the > two I can think of needing this immediately) sort of calls for making > the code architecture agnostic since past 2, you need something that scales. I believe the use-case is for ARM64 at this moment. > > There is already code today under kernel/dma/contiguous.c that is only > activated on a CONFIG_OF=y && CONFIG_OF_RESERVED_MEM=y system, this is > no different. > -- > Florian
Re: [RFC PATCH v3 5/6] dt-bindings: of: Add restricted DMA pool
On 1/7/21 10:00 AM, Konrad Rzeszutek Wilk wrote: >>> >>> >>> - Nothing stops the physical device from bypassing the SWIOTLB buffer. >>>That is if an errant device screwed up the length or DMA address, the >>>SWIOTLB would gladly do what the device told it do? >> >> So the system needs to provide a way to lock down the memory access, e.g. >> MPU. > > OK! Would it be prudent to have this in the description above perhaps? Yes this is something that must be documented as a requirement for the restricted DMA pool users, otherwise attempting to do restricted DMA pool is no different than say, using a device private CMA region. Without the enforcement, this is just a best effort. -- Florian
Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool
On 1/7/21 9:57 AM, Konrad Rzeszutek Wilk wrote: > On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote: >> Hi Greg and Konrad, >> >> This change is intended to be non-arch specific. Any arch that lacks DMA >> access >> control and has devices not behind an IOMMU can make use of it. Could you >> share >> why you think this should be arch specific? > > The idea behind non-arch specific code is it to be generic. The devicetree > is specific to PowerPC, Sparc, and ARM, and not to x86 - hence it should > be in arch specific code. In premise the same code could be used with an ACPI enabled system with an appropriate service to identify the restricted DMA regions and unlock them. More than 1 architecture requiring this function (ARM and ARM64 are the two I can think of needing this immediately) sort of calls for making the code architecture agnostic since past 2, you need something that scales. There is already code today under kernel/dma/contiguous.c that is only activated on a CONFIG_OF=y && CONFIG_OF_RESERVED_MEM=y system, this is no different. -- Florian
Re: [RFC PATCH v3 0/6] Restricted DMA
On 1/7/21 9:42 AM, Claire Chang wrote: >> Can you explain how ATF gets involved and to what extent it does help, >> besides enforcing a secure region from the ARM CPU's perpsective? Does >> the PCIe root complex not have an IOMMU but can somehow be denied access >> to a region that is marked NS=0 in the ARM CPU's MMU? If so, that is >> still some sort of basic protection that the HW enforces, right? > > We need the ATF support for memory MPU (memory protection unit). > Restricted DMA (with reserved-memory in dts) makes sure the predefined memory > region is for PCIe DMA only, but we still need MPU to locks down PCIe access > to > that specific regions. OK so you do have a protection unit of some sort to enforce which region in DRAM the PCIE bridge is allowed to access, that makes sense, otherwise the restricted DMA region would only be a hint but nothing you can really enforce. This is almost entirely analogous to our systems then. There may be some value in standardizing on an ARM SMCCC call then since you already support two different SoC vendors. > >> >> On Broadcom STB SoCs we have had something similar for a while however >> and while we don't have an IOMMU for the PCIe bridge, we do have a a >> basic protection mechanism whereby we can configure a region in DRAM to >> be PCIe read/write and CPU read/write which then gets used as the PCIe >> inbound region for the PCIe EP. By default the PCIe bridge is not >> allowed access to DRAM so we must call into a security agent to allow >> the PCIe bridge to access the designated DRAM region. >> >> We have done this using a private CMA area region assigned via Device >> Tree, assigned with a and requiring the PCIe EP driver to use >> dma_alloc_from_contiguous() in order to allocate from this device >> private CMA area. The only drawback with that approach is that it >> requires knowing how much memory you need up front for buffers and DMA >> descriptors that the PCIe EP will need to process. The problem is that >> it requires driver modifications and that does not scale over the number >> of PCIe EP drivers, some we absolutely do not control, but there is no >> need to bounce buffer. Your approach scales better across PCIe EP >> drivers however it does require bounce buffering which could be a >> performance hit. > > Only the streaming DMA (map/unmap) needs bounce buffering. True, and typically only on transmit since you don't really control where the sk_buff are allocated from, right? On RX since you need to hand buffer addresses to the WLAN chip prior to DMA, you can allocate them from a pool that already falls within the restricted DMA region, right? > I also added alloc/free support in this series > (https://lore.kernel.org/patchwork/patch/1360995/), so dma_direct_alloc() will > try to allocate memory from the predefined memory region. > > As for the performance hit, it should be similar to the default swiotlb. > Here are my experiment results. Both SoCs lack IOMMU for PCIe. > > PCIe wifi vht80 throughput - > > MTK SoC tcp_tx tcp_rxudp_tx udp_rx > w/o Restricted DMA 244.1 134.66 312.56 350.79 > w/ Restricted DMA246.95 136.59 363.21 351.99 > > Rockchip SoC tcp_tx tcp_rxudp_tx udp_rx > w/o Restricted DMA 237.87 133.86 288.28 361.88 > w/ Restricted DMA256.01 130.95 292.28 353.19 How come you get better throughput with restricted DMA? Is it because doing DMA to/from a contiguous region allows for better grouping of transactions from the DRAM controller's perspective somehow? > > The CPU usage doesn't increase too much either. > Although I didn't measure the CPU usage very precisely, it's ~3% with a single > big core (Cortex-A72) and ~5% with a single small core (Cortex-A53). > > Thanks! > >> >> Thanks! >> -- >> Florian -- Florian
Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool
On Fri, Jan 08, 2021 at 01:39:18AM +0800, Claire Chang wrote: > Hi Greg and Konrad, > > This change is intended to be non-arch specific. Any arch that lacks DMA > access > control and has devices not behind an IOMMU can make use of it. Could you > share > why you think this should be arch specific? The idea behind non-arch specific code is it to be generic. The devicetree is specific to PowerPC, Sparc, and ARM, and not to x86 - hence it should be in arch specific code. > > Thanks!
Re: [RFC PATCH v3 0/6] Restricted DMA
On Thu, Jan 7, 2021 at 2:48 AM Florian Fainelli wrote: > > Hi, > > First of all let me say that I am glad that someone is working on a > upstream solution for this issue, would appreciate if you could CC and > Jim Quinlan on subsequent submissions. Sure! > > On 1/5/21 7:41 PM, Claire Chang wrote: > > This series implements mitigations for lack of DMA access control on > > systems without an IOMMU, which could result in the DMA accessing the > > system memory at unexpected times and/or unexpected addresses, possibly > > leading to data leakage or corruption. > > > > For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is > > not behind an IOMMU. As PCI-e, by design, gives the device full access to > > system memory, a vulnerability in the Wi-Fi firmware could easily escalate > > to a full system exploit (remote wifi exploits: [1a], [1b] that shows a > > full chain of exploits; [2], [3]). > > > > To mitigate the security concerns, we introduce restricted DMA. Restricted > > DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a > > specially allocated region and does memory allocation from the same region. > > The feature on its own provides a basic level of protection against the DMA > > overwriting buffer contents at unexpected times. However, to protect > > against general data leakage and system memory corruption, the system needs > > to provide a way to restrict the DMA to a predefined memory region (this is > > usually done at firmware level, e.g. in ATF on some ARM platforms). > > Can you explain how ATF gets involved and to what extent it does help, > besides enforcing a secure region from the ARM CPU's perpsective? Does > the PCIe root complex not have an IOMMU but can somehow be denied access > to a region that is marked NS=0 in the ARM CPU's MMU? If so, that is > still some sort of basic protection that the HW enforces, right? We need the ATF support for memory MPU (memory protection unit). Restricted DMA (with reserved-memory in dts) makes sure the predefined memory region is for PCIe DMA only, but we still need MPU to locks down PCIe access to that specific regions. > > On Broadcom STB SoCs we have had something similar for a while however > and while we don't have an IOMMU for the PCIe bridge, we do have a a > basic protection mechanism whereby we can configure a region in DRAM to > be PCIe read/write and CPU read/write which then gets used as the PCIe > inbound region for the PCIe EP. By default the PCIe bridge is not > allowed access to DRAM so we must call into a security agent to allow > the PCIe bridge to access the designated DRAM region. > > We have done this using a private CMA area region assigned via Device > Tree, assigned with a and requiring the PCIe EP driver to use > dma_alloc_from_contiguous() in order to allocate from this device > private CMA area. The only drawback with that approach is that it > requires knowing how much memory you need up front for buffers and DMA > descriptors that the PCIe EP will need to process. The problem is that > it requires driver modifications and that does not scale over the number > of PCIe EP drivers, some we absolutely do not control, but there is no > need to bounce buffer. Your approach scales better across PCIe EP > drivers however it does require bounce buffering which could be a > performance hit. Only the streaming DMA (map/unmap) needs bounce buffering. I also added alloc/free support in this series (https://lore.kernel.org/patchwork/patch/1360995/), so dma_direct_alloc() will try to allocate memory from the predefined memory region. As for the performance hit, it should be similar to the default swiotlb. Here are my experiment results. Both SoCs lack IOMMU for PCIe. PCIe wifi vht80 throughput - MTK SoC tcp_tx tcp_rxudp_tx udp_rx w/o Restricted DMA 244.1 134.66 312.56 350.79 w/ Restricted DMA246.95 136.59 363.21 351.99 Rockchip SoC tcp_tx tcp_rxudp_tx udp_rx w/o Restricted DMA 237.87 133.86 288.28 361.88 w/ Restricted DMA256.01 130.95 292.28 353.19 The CPU usage doesn't increase too much either. Although I didn't measure the CPU usage very precisely, it's ~3% with a single big core (Cortex-A72) and ~5% with a single small core (Cortex-A53). Thanks! > > Thanks! > -- > Florian
Re: [RFC PATCH v3 5/6] dt-bindings: of: Add restricted DMA pool
On Thu, Jan 7, 2021 at 2:58 AM Konrad Rzeszutek Wilk wrote: > > On Wed, Jan 06, 2021 at 11:41:23AM +0800, Claire Chang wrote: > > Introduce the new compatible string, restricted-dma-pool, for restricted > > DMA. One can specify the address and length of the restricted DMA memory > > region by restricted-dma-pool in the device tree. > > > > Signed-off-by: Claire Chang > > --- > > .../reserved-memory/reserved-memory.txt | 24 +++ > > 1 file changed, 24 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > index e8d3096d922c..44975e2a1fd2 100644 > > --- a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt > > @@ -51,6 +51,20 @@ compatible (optional) - standard definition > >used as a shared pool of DMA buffers for a set of devices. It can > >be used by an operating system to instantiate the necessary pool > >management subsystem if necessary. > > +- restricted-dma-pool: This indicates a region of memory meant to > > be > > + used as a pool of restricted DMA buffers for a set of devices. > > The > > + memory region would be the only region accessible to those > > devices. > > + When using this, the no-map and reusable properties must not be > > set, > > + so the operating system can create a virtual mapping that will > > be used > > + for synchronization. The main purpose for restricted DMA is to > > + mitigate the lack of DMA access control on systems without an > > IOMMU, > > + which could result in the DMA accessing the system memory at > > + unexpected times and/or unexpected addresses, possibly leading > > to data > > + leakage or corruption. The feature on its own provides a basic > > level > > + of protection against the DMA overwriting buffer contents at > > + unexpected times. However, to protect against general data > > leakage and > > + system memory corruption, the system needs to provide way to > > restrict > > + the DMA to a predefined memory region. > > Heya! > > I think I am missing something obvious here so please bear with my > questions: > > - This code adds the means of having the SWIOTLB pool tied to a specific >memory correct? It doesn't affect the existing SWIOTLB. It just utilizes the existing SWIOTLB code to create another DMA pool tied to a specific memory region for a given set of devices. It bounces the streaming DMA (map/unmap) in and out of that region and does the memory allocation (dma_direct_alloc) from the same region. > > > - Nothing stops the physical device from bypassing the SWIOTLB buffer. >That is if an errant device screwed up the length or DMA address, the >SWIOTLB would gladly do what the device told it do? So the system needs to provide a way to lock down the memory access, e.g. MPU. > > - This has to be combined with SWIOTLB-force-ish to always use the >bounce buffer, otherwise you could still do DMA without using >SWIOTLB (by not hitting the criteria for needing to use SWIOTLB)? Since restricted DMA is for the devices that are not behind an IOMMU, I change the criteria `if (unlikely(swiotlb_force == SWIOTLB_FORCE))` to `if (unlikely(swiotlb_force == SWIOTLB_FORCE) || dev->dma_io_tlb_mem)` in dma_direct_map_page(). Also, even if SWIOTLB=force, the restricted DMA pool is preferred if available (get_io_tlb_mem in https://lore.kernel.org/patchwork/patch/1360995/). Thanks!
Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool
Hi Greg and Konrad, This change is intended to be non-arch specific. Any arch that lacks DMA access control and has devices not behind an IOMMU can make use of it. Could you share why you think this should be arch specific? Thanks!
[PATCH v2] powerpc/mce: Remove per cpu variables from MCE handlers
Access to per-cpu variables requires translation to be enabled on
pseries machine running in hash mmu mode, Since part of MCE handler
runs in realmode and part of MCE handling code is shared between ppc
architectures pseries and powernv, it becomes difficult to manage
these variables differently on different architectures, So have
these variables in paca instead of having them as per-cpu variables
to avoid complications.
Maximum recursive depth of MCE is 4, Considering the maximum depth
allowed reduce the size of event to 10 from 100.
Signed-off-by: Ganesh Goudar
---
v2: Dynamically allocate memory for machine check event info
---
arch/powerpc/include/asm/mce.h | 21 +++-
arch/powerpc/include/asm/paca.h| 4 ++
arch/powerpc/kernel/mce.c | 86 ++
arch/powerpc/kernel/setup-common.c | 2 +-
4 files changed, 78 insertions(+), 35 deletions(-)
diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
index e6c27ae843dc..8d6e3a7a9f37 100644
--- a/arch/powerpc/include/asm/mce.h
+++ b/arch/powerpc/include/asm/mce.h
@@ -204,7 +204,18 @@ struct mce_error_info {
boolignore_event;
};
-#define MAX_MC_EVT 100
+#define MAX_MC_EVT 10
+
+struct mce_info {
+ int mce_nest_count;
+ struct machine_check_event mce_event[MAX_MC_EVT];
+ /* Queue for delayed MCE events. */
+ int mce_queue_count;
+ struct machine_check_event mce_event_queue[MAX_MC_EVT];
+ /* Queue for delayed MCE UE events. */
+ int mce_ue_count;
+ struct machine_check_event mce_ue_event_queue[MAX_MC_EVT];
+};
/* Release flags for get_mce_event() */
#define MCE_EVENT_RELEASE true
@@ -233,5 +244,13 @@ long __machine_check_early_realmode_p7(struct pt_regs
*regs);
long __machine_check_early_realmode_p8(struct pt_regs *regs);
long __machine_check_early_realmode_p9(struct pt_regs *regs);
long __machine_check_early_realmode_p10(struct pt_regs *regs);
+#define get_mce_info() local_paca->mce_info
+#endif /* CONFIG_PPC_BOOK3S_64 */
+
+#ifdef CONFIG_PPC_BOOK3S_64
+void mce_init(void);
+#else
+static inline void mce_init(void) { };
#endif /* CONFIG_PPC_BOOK3S_64 */
+
#endif /* __ASM_PPC64_MCE_H__ */
diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
index 9454d29ff4b4..38e0c55e845d 100644
--- a/arch/powerpc/include/asm/paca.h
+++ b/arch/powerpc/include/asm/paca.h
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
@@ -273,6 +274,9 @@ struct paca_struct {
#ifdef CONFIG_MMIOWB
struct mmiowb_state mmiowb_state;
#endif
+#ifdef CONFIG_PPC_BOOK3S_64
+ struct mce_info *mce_info;
+#endif /* CONFIG_PPC_BOOK3S_64 */
} cacheline_aligned;
extern void copy_mm_to_paca(struct mm_struct *mm);
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index 9f3e133b57b7..14142ddbedf2 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -17,23 +17,12 @@
#include
#include
#include
+#include
#include
#include
#include
-static DEFINE_PER_CPU(int, mce_nest_count);
-static DEFINE_PER_CPU(struct machine_check_event[MAX_MC_EVT], mce_event);
-
-/* Queue for delayed MCE events. */
-static DEFINE_PER_CPU(int, mce_queue_count);
-static DEFINE_PER_CPU(struct machine_check_event[MAX_MC_EVT], mce_event_queue);
-
-/* Queue for delayed MCE UE events. */
-static DEFINE_PER_CPU(int, mce_ue_count);
-static DEFINE_PER_CPU(struct machine_check_event[MAX_MC_EVT],
- mce_ue_event_queue);
-
static void machine_check_process_queued_event(struct irq_work *work);
static void machine_check_ue_irq_work(struct irq_work *work);
static void machine_check_ue_event(struct machine_check_event *evt);
@@ -103,8 +92,8 @@ void save_mce_event(struct pt_regs *regs, long handled,
struct mce_error_info *mce_err,
uint64_t nip, uint64_t addr, uint64_t phys_addr)
{
- int index = __this_cpu_inc_return(mce_nest_count) - 1;
- struct machine_check_event *mce = this_cpu_ptr(&mce_event[index]);
+ int index = get_mce_info()->mce_nest_count++;
+ struct machine_check_event *mce = &get_mce_info()->mce_event[index];
/*
* Return if we don't have enough space to log mce event.
@@ -191,7 +180,7 @@ void save_mce_event(struct pt_regs *regs, long handled,
*/
int get_mce_event(struct machine_check_event *mce, bool release)
{
- int index = __this_cpu_read(mce_nest_count) - 1;
+ int index = get_mce_info()->mce_nest_count - 1;
struct machine_check_event *mc_evt;
int ret = 0;
@@ -201,7 +190,7 @@ int get_mce_event(struct machine_check_event *mce, bool
release)
/* Check if we have MCE info to process. */
if (index < MAX_MC_EVT) {
- mc_evt = this_cpu_ptr(&mce_event[index]);
+ mc_evt = &get_mce_info()->mce_event[index];
/* Copy the event structure and re
