Re: [PATCH] arm64: PCI: Enable SMC conduit

Hi Marcin, Many thanks for your thoughtful, heartfelt response, and I don't disagree with your sentiments. The truth is that we have a messy situation. As a collective community of people who are passionate about the success of Arm in general purpose systems, I know many who would share my

Re: [PATCH v3 2/2] arm64: mm: reserve CMA and crashkernel in ZONE_DMA32

On 3/22/21 2:34 PM, Jon Masters wrote: Hi Nicolas, On 11/7/19 4:56 AM, Nicolas Saenz Julienne wrote: With the introduction of ZONE_DMA in arm64 we moved the default CMA and crashkernel reservation into that area. This caused a regression on big machines that need big CMA and crashkernel

Re: [PATCH v3 2/2] arm64: mm: reserve CMA and crashkernel in ZONE_DMA32

Hi Nicolas, On 11/7/19 4:56 AM, Nicolas Saenz Julienne wrote: With the introduction of ZONE_DMA in arm64 we moved the default CMA and crashkernel reservation into that area. This caused a regression on big machines that need big CMA and crashkernel reservations. Note that ZONE_DMA is only 1GB

Re: [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool

On 1/7/21 1:09 PM, 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

Re: [PATCH] arm64: PCI: Enable SMC conduit

Hi will, everyone, On 1/7/21 1:14 PM, Will Deacon wrote: On Mon, Jan 04, 2021 at 10:57:35PM -0600, Jeremy Linton wrote: Given that most arm64 platform's PCI implementations needs quirks to deal with problematic config accesses, this is a good place to apply a firmware abstraction. The ARM PCI

Re: [RFC PATCH 5/9] cxl/mem: Find device capabilities

On 11/11/20 12:43 AM, Ben Widawsky wrote: + case CXL_CAPABILITIES_CAP_ID_SECONDARY_MAILBOX: + dev_dbg(>pdev->dev, + "found UNSUPPORTED Secondary Mailbox capability\n"); Per spec, the secondary mailbox is intended for use by

Re: Litmus test for question from Al Viro

On 10/1/20 12:15 PM, Alan Stern wrote: On Wed, Sep 30, 2020 at 09:51:16PM -0700, Paul E. McKenney wrote: Hello! Al Viro posted the following query: fun question regarding barriers, if you have time for that

Re: dma-coherent property for PCIe Root

On 9/14/20 1:23 AM, Valmiki wrote: Hi All, How does "dma-coherent" property will work for PCIe as RC on an ARM SOC ? Because the end point device drivers are the one which will request dma buffers and Root port driver doesn't involve in data path of end point except for handling interrupts.

Re: Linux 5.3-rc8

On 9/10/19 12:21 AM, Ahmed S. Darwish wrote: > Can this even be considered a user-space breakage? I'm honestly not > sure. On my modern RDRAND-capable x86, just running rng-tools rngd(8) > early-on fixes the problem. I'm not sure about the status of older > CPUs though. Tangent: I asked aloud on

Re: Linux 5.3-rc8

On 9/10/19 12:21 AM, Ahmed S. Darwish wrote: > Can this even be considered a user-space breakage? I'm honestly not > sure. On my modern RDRAND-capable x86, just running rng-tools rngd(8) > early-on fixes the problem. I'm not sure about the status of older > CPUs though. Tangent: I asked aloud on

Re: [PATCH v3] Documentation: Add section about CPU vulnerabilities for Spectre

On 6/17/19 4:22 PM, Jon Masters wrote: >> + For kernel code that has been identified where data pointers could >> + potentially be influenced for Spectre attacks, new "nospec" accessor >> + macros are used to prevent speculative loading of data. > > Mayb

Re: [PATCH v3] Documentation: Add section about CPU vulnerabilities for Spectre

Hi Tim, Nice writeup. A few suggestions inline. On 6/17/19 3:11 PM, Tim Chen wrote: > +In Spectre variant 2 attacks, the attacker can steer speculative indirect > +branches in the victim to gadget code by poisoning the branch target > +buffer of a CPU used for predicting indirect branch

Re: [LSF/MM TOPIC] FS, MM, and stable trees

On 3/20/19 2:28 AM, Greg KH wrote: > On Wed, Mar 20, 2019 at 02:14:09AM -0400, Jon Masters wrote: >> On 3/20/19 1:06 AM, Greg KH wrote: >>> On Tue, Mar 19, 2019 at 11:46:09PM -0400, Jon Masters wrote: >>>> On 2/13/19 2:52 PM, Greg KH wrote: >>>>> On

Re: [LSF/MM TOPIC] FS, MM, and stable trees

On 3/20/19 1:06 AM, Greg KH wrote: > On Tue, Mar 19, 2019 at 11:46:09PM -0400, Jon Masters wrote: >> On 2/13/19 2:52 PM, Greg KH wrote: >>> On Wed, Feb 13, 2019 at 02:25:12PM -0500, Sasha Levin wrote: >> >>>> So really, it sounds like a low hanging fruit: we

Re: [LSF/MM TOPIC] FS, MM, and stable trees

On 2/13/19 2:52 PM, Greg KH wrote: > On Wed, Feb 13, 2019 at 02:25:12PM -0500, Sasha Levin wrote: >> So really, it sounds like a low hanging fruit: we don't really need to >> write much more testing code code nor do we have to refactor existing >> test suites. We just need to make sure the right

Re: [PATCH v2 00/11] arch/x86: AMD QoS support

On 10/5/18 4:55 PM, Moger, Babu wrote: > The public specification for this feature is available at > https://www.amd.com/system/files/TechDocs/56375_Quality_of_Service_Extensions.pdf 404 error

Re: [PATCH v2 00/11] arch/x86: AMD QoS support

On 10/5/18 4:55 PM, Moger, Babu wrote: > The public specification for this feature is available at > https://www.amd.com/system/files/TechDocs/56375_Quality_of_Service_Extensions.pdf 404 error

Re: [SCHEDULER] Performance drop in 4.19 compared to 4.18 kernel

On 9/7/18 5:34 AM, Jirka Hladky wrote: > We would also be more than happy to test the new patches for the > performance - please let us know if you are interested. We have a > pool of 1 NUMA up to 8 NUMA boxes for that, both AMD and Intel, > covering different CPU generations from Sandy Bridge

Re: [SCHEDULER] Performance drop in 4.19 compared to 4.18 kernel

On 9/7/18 5:34 AM, Jirka Hladky wrote: > We would also be more than happy to test the new patches for the > performance - please let us know if you are interested. We have a > pool of 1 NUMA up to 8 NUMA boxes for that, both AMD and Intel, > covering different CPU generations from Sandy Bridge

Re: [RFC 00/60] Coscheduling for Linux

On 9/7/18 5:39 PM, Jan H. Schönherr wrote: > The collective context switch from one coscheduled set of tasks to another > -- while fast -- is not atomic. If a use-case needs the absolute guarantee > that all tasks of the previous set have stopped executing before any task > of the next set starts

Re: [RFC 00/60] Coscheduling for Linux

On 9/7/18 5:39 PM, Jan H. Schönherr wrote: > The collective context switch from one coscheduled set of tasks to another > -- while fast -- is not atomic. If a use-case needs the absolute guarantee > that all tasks of the previous set have stopped executing before any task > of the next set starts

Re: [PATCH 2/2] x86/speculation: Provide application property based STIBP protection

Quick reply: I agree, I'm just supporting this :) -- Computer Architect > On Oct 2, 2018, at 11:43, Jiri Kosina wrote: > > On Tue, 2 Oct 2018, Jon Masters wrote: > >>> This patch provides an application property based spectre_v2 >>> protection with STIBP agains

Re: [PATCH 2/2] x86/speculation: Provide application property based STIBP protection

Quick reply: I agree, I'm just supporting this :) -- Computer Architect > On Oct 2, 2018, at 11:43, Jiri Kosina wrote: > > On Tue, 2 Oct 2018, Jon Masters wrote: > >>> This patch provides an application property based spectre_v2 >>> protection with STIBP agains

Re: [PATCH 2/2] x86/speculation: Provide application property based STIBP protection

On 9/19/18 5:35 PM, Tim Chen wrote: > This patch provides an application property based spectre_v2 > protection with STIBP against attack from another app from > a sibling hyper-thread. For security sensitive non-dumpable > app, STIBP will be turned on before switching to it for Intel >

Re: [PATCH 2/2] x86/speculation: Provide application property based STIBP protection

On 9/19/18 5:35 PM, Tim Chen wrote: > This patch provides an application property based spectre_v2 > protection with STIBP against attack from another app from > a sibling hyper-thread. For security sensitive non-dumpable > app, STIBP will be turned on before switching to it for Intel >

Re: [RFC PATCH 00/11] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64

Tnx -- Computer Architect > On Sep 13, 2018, at 11:52, Will Deacon wrote: > >> On Fri, Sep 07, 2018 at 02:36:08AM -0400, Jon Masters wrote: >>> On 09/05/2018 08:28 AM, Will Deacon wrote: >>>> On Tue, Sep 04, 2018 at 02:38:02PM -0400, Jon Masters wr

Re: [RFC PATCH 00/11] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64

Tnx -- Computer Architect > On Sep 13, 2018, at 11:52, Will Deacon wrote: > >> On Fri, Sep 07, 2018 at 02:36:08AM -0400, Jon Masters wrote: >>> On 09/05/2018 08:28 AM, Will Deacon wrote: >>>> On Tue, Sep 04, 2018 at 02:38:02PM -0400, Jon Masters wr

Re: [RFC PATCH 00/11] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64

On 09/05/2018 08:28 AM, Will Deacon wrote: > On Tue, Sep 04, 2018 at 02:38:02PM -0400, Jon Masters wrote: >> On 08/24/2018 11:52 AM, Will Deacon wrote: >> >>> I hacked up this RFC on the back of the recent changes to the mmu_gather >>> stuff in mainline. It's

Re: [RFC PATCH 00/11] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64

On 09/05/2018 08:28 AM, Will Deacon wrote: > On Tue, Sep 04, 2018 at 02:38:02PM -0400, Jon Masters wrote: >> On 08/24/2018 11:52 AM, Will Deacon wrote: >> >>> I hacked up this RFC on the back of the recent changes to the mmu_gather >>> stuff in mainline. It's

Re: [RFC PATCH 00/11] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64

On 08/24/2018 11:52 AM, Will Deacon wrote: > I hacked up this RFC on the back of the recent changes to the mmu_gather > stuff in mainline. It's had a bit of testing and it looks pretty good so > far. I will request the server folks go and test this. You'll probably remember a couple of parts

Re: [RFC PATCH 00/11] Avoid synchronous TLB invalidation for intermediate page-table entries on arm64

On 08/24/2018 11:52 AM, Will Deacon wrote: > I hacked up this RFC on the back of the recent changes to the mmu_gather > stuff in mainline. It's had a bit of testing and it looks pretty good so > far. I will request the server folks go and test this. You'll probably remember a couple of parts

Re: [PATCH 2/3] ACPI: SPCR: Add support for AMD CT/SZ

On 03/13/2018 08:36 PM, Daniel Kurtz wrote: > AMD Carrizo / Stoneyridge use a DesignWare 8250 UART that uses a special > earlycon setup handler to configure its input clock in order to compute > baud rate divisor registers. > Detect them by examining the OEMID field in the SPCR header, and pass >

Re: [PATCH 2/3] ACPI: SPCR: Add support for AMD CT/SZ

On 03/13/2018 08:36 PM, Daniel Kurtz wrote: > AMD Carrizo / Stoneyridge use a DesignWare 8250 UART that uses a special > earlycon setup handler to configure its input clock in order to compute > baud rate divisor registers. > Detect them by examining the OEMID field in the SPCR header, and pass >

FLR on AER

Hi Bjorn, It looks like the AER driver won’t do a device FLR but instead will default to progressively bigger hammers. Am I missing something? Jon. -- Computer Architect | Sent from my 64-bit #ARM Powered phone

FLR on AER

Hi Bjorn, It looks like the AER driver won’t do a device FLR but instead will default to progressively bigger hammers. Am I missing something? Jon. -- Computer Architect | Sent from my 64-bit #ARM Powered phone

Re: Patch "[Variant 2/Spectre-v2] arm64: Implement branch predictor hardening for Falkor" has been added to the 4.14-stable tree

On 02/14/2018 11:16 AM, Timur Tabi wrote: > On Wed, Feb 14, 2018 at 7:53 AM, wrote: >> >> This is a note to let you know that I've just added the patch titled >> >> [Variant 2/Spectre-v2] arm64: Implement branch predictor hardening for >> Falkor >> >> to the

Re: Patch "[Variant 2/Spectre-v2] arm64: Implement branch predictor hardening for Falkor" has been added to the 4.14-stable tree

On 02/14/2018 11:16 AM, Timur Tabi wrote: > On Wed, Feb 14, 2018 at 7:53 AM, wrote: >> >> This is a note to let you know that I've just added the patch titled >> >> [Variant 2/Spectre-v2] arm64: Implement branch predictor hardening for >> Falkor >> >> to the 4.14-stable tree which can be

Re: [PATCH] arm64: Make L1_CACHE_SHIFT configurable

On 02/12/2018 07:17 PM, Florian Fainelli wrote: > On 02/12/2018 04:10 PM, Timur Tabi wrote: >> On 02/12/2018 05:57 PM, Florian Fainelli wrote: >>> That is debatable, is there a good publicly available table of what the >>> typical L1 cache line size is on ARMv8 platforms? With a server hat on...

Re: [PATCH] arm64: Make L1_CACHE_SHIFT configurable

On 02/12/2018 07:17 PM, Florian Fainelli wrote: > On 02/12/2018 04:10 PM, Timur Tabi wrote: >> On 02/12/2018 05:57 PM, Florian Fainelli wrote: >>> That is debatable, is there a good publicly available table of what the >>> typical L1 cache line size is on ARMv8 platforms? With a server hat on...

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On 02/16/2018 07:10 AM, David Woodhouse wrote: > On Fri, 2018-02-16 at 12:04 +0100, Paolo Bonzini wrote: >> On 16/02/2018 11:21, David Woodhouse wrote: >>> Even if the guest doesn't have/support IBRS_ALL, and is frobbing the >>> (now emulated) MSR on every kernel entry/exit, that's *still* going

Re: [PATCH 2/2] x86/speculation: Support "Enhanced IBRS" on future CPUs

On 02/16/2018 07:10 AM, David Woodhouse wrote: > On Fri, 2018-02-16 at 12:04 +0100, Paolo Bonzini wrote: >> On 16/02/2018 11:21, David Woodhouse wrote: >>> Even if the guest doesn't have/support IBRS_ALL, and is frobbing the >>> (now emulated) MSR on every kernel entry/exit, that's *still* going

Re: [PATCH v3] ACPI / tables: Add IORT to injectable table list

On 02/02/2018 07:12 AM, Wang, Dongsheng wrote: > Hey, Hanjun, > > On 2018/2/2 19:54:24, "Hanjun Guo" wrote: > >> On 2018/2/2 18:25, Yang Shunyong wrote: >>> Loading IORT table from initrd is used to fix firmware IORT defects. >> >> I don't think this fix "firmware

Re: [PATCH v3] ACPI / tables: Add IORT to injectable table list

On 02/02/2018 07:12 AM, Wang, Dongsheng wrote: > Hey, Hanjun, > > On 2018/2/2 19:54:24, "Hanjun Guo" wrote: > >> On 2018/2/2 18:25, Yang Shunyong wrote: >>> Loading IORT table from initrd is used to fix firmware IORT defects. >> >> I don't think this fix "firmware defects", it just for debug

Re: [PATCH] PCI: Add quirk for Cavium Thunder-X2 PCIe erratum #173

Hi Bjorn, Rafael, others, On 02/15/2018 06:39 PM, Bjorn Helgaas wrote: > On Thu, Feb 15, 2018 at 10:57:25PM +0100, Rafael J. Wysocki wrote: >> On Wednesday, February 14, 2018 9:16:53 PM CET Bjorn Helgaas wrote: >>> On Wed, Feb 14, 2018 at 04:58:08PM +0530, George Cherian wrote: On 02/13/2018

Re: [PATCH] PCI: Add quirk for Cavium Thunder-X2 PCIe erratum #173

Hi Bjorn, Rafael, others, On 02/15/2018 06:39 PM, Bjorn Helgaas wrote: > On Thu, Feb 15, 2018 at 10:57:25PM +0100, Rafael J. Wysocki wrote: >> On Wednesday, February 14, 2018 9:16:53 PM CET Bjorn Helgaas wrote: >>> On Wed, Feb 14, 2018 at 04:58:08PM +0530, George Cherian wrote: On 02/13/2018

Re: [PATCH v4 00/17] arm64: Add SMCCC v1.1 support and CVE-2017-5715 (Spectre variant 2) mitigation

Hi Marc, all, On 02/06/2018 12:56 PM, Marc Zyngier wrote: > ARM has recently published a SMC Calling Convention (SMCCC) > specification update[1] that provides an optimised calling convention > and optional, discoverable support for mitigating CVE-2017-5715. ARM > Trusted Firmware (ATF) has

Re: [PATCH v4 00/17] arm64: Add SMCCC v1.1 support and CVE-2017-5715 (Spectre variant 2) mitigation

Hi Marc, all, On 02/06/2018 12:56 PM, Marc Zyngier wrote: > ARM has recently published a SMC Calling Convention (SMCCC) > specification update[1] that provides an optimised calling convention > and optional, discoverable support for mitigating CVE-2017-5715. ARM > Trusted Firmware (ATF) has

Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process

Hi Peter, David, all, First a quick note on David's earlier comment, about this optimization being still up for debate. The problem with this optimization as-is is that it doesn't protect userspace-to-userspace unless applications are rebuilt and we get the infrastructure to handle that (ELF,

Re: [RFC 04/10] x86/mm: Only flush indirect branches when switching into non dumpable process

Hi Peter, David, all, First a quick note on David's earlier comment, about this optimization being still up for debate. The problem with this optimization as-is is that it doesn't protect userspace-to-userspace unless applications are rebuilt and we get the infrastructure to handle that (ELF,

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

On 01/07/2018 04:48 PM, Thomas Gleixner wrote: > +#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES > + > +ssize_t __weak cpu_show_meltdown(struct device *dev, > + struct device_attribute *attr, char *buf) > +{ > + return sprintf(buf, "Not affected\n"); > +} > + >

Re: [patch V2 1/2] sysfs/cpu: Add vulnerability folder

On 01/07/2018 04:48 PM, Thomas Gleixner wrote: > +#ifdef CONFIG_GENERIC_CPU_VULNERABILITIES > + > +ssize_t __weak cpu_show_meltdown(struct device *dev, > + struct device_attribute *attr, char *buf) > +{ > + return sprintf(buf, "Not affected\n"); > +} > + >

Re: [PATCH v3 1/2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/22/2018 06:33 AM, Will Deacon wrote: > On Fri, Jan 19, 2018 at 04:22:47AM -0800, Jayachandran C wrote: >> Use PSCI based mitigation for speculative execution attacks targeting >> the branch predictor. We use the same mechanism as the one used for >> Cortex-A CPUs, we expect the PSCI version

Re: [PATCH v3 1/2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/22/2018 06:33 AM, Will Deacon wrote: > On Fri, Jan 19, 2018 at 04:22:47AM -0800, Jayachandran C wrote: >> Use PSCI based mitigation for speculative execution attacks targeting >> the branch predictor. We use the same mechanism as the one used for >> Cortex-A CPUs, we expect the PSCI version

Re: [PATCH v3 2/2] arm64: Turn on KPTI only on CPUs that need it

On 01/22/2018 06:41 AM, Will Deacon wrote: > On Fri, Jan 19, 2018 at 04:22:48AM -0800, Jayachandran C wrote: >> Whitelist Broadcom Vulcan/Cavium ThunderX2 processors in >> unmap_kernel_at_el0(). These CPUs are not vulnerable to >> CVE-2017-5754 and do not need KPTI when KASLR is off. >> >>

Re: [PATCH v3 2/2] arm64: Turn on KPTI only on CPUs that need it

On 01/22/2018 06:41 AM, Will Deacon wrote: > On Fri, Jan 19, 2018 at 04:22:48AM -0800, Jayachandran C wrote: >> Whitelist Broadcom Vulcan/Cavium ThunderX2 processors in >> unmap_kernel_at_el0(). These CPUs are not vulnerable to >> CVE-2017-5754 and do not need KPTI when KASLR is off. >> >>

Re: [PATCH v3 1/2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/19/2018 07:22 AM, Jayachandran C wrote: > Use PSCI based mitigation for speculative execution attacks targeting > the branch predictor. We use the same mechanism as the one used for > Cortex-A CPUs, we expect the PSCI version call to have a side effect > of clearing the BTBs. > >

Re: [PATCH v3 1/2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/19/2018 07:22 AM, Jayachandran C wrote: > Use PSCI based mitigation for speculative execution attacks targeting > the branch predictor. We use the same mechanism as the one used for > Cortex-A CPUs, we expect the PSCI version call to have a side effect > of clearing the BTBs. > >

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

Hi JC, Will, On 01/18/2018 06:28 PM, Jayachandran C wrote: > On Thu, Jan 18, 2018 at 01:27:15PM -0500, Jon Masters wrote: >> On 01/18/2018 12:56 PM, Jayachandran C wrote: >>> On Thu, Jan 18, 2018 at 01:53:55PM +, Will Deacon wrote: >>> I think in this case we have

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

Hi JC, Will, On 01/18/2018 06:28 PM, Jayachandran C wrote: > On Thu, Jan 18, 2018 at 01:27:15PM -0500, Jon Masters wrote: >> On 01/18/2018 12:56 PM, Jayachandran C wrote: >>> On Thu, Jan 18, 2018 at 01:53:55PM +, Will Deacon wrote: >>> I think in this case we have

Re: [v2,03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3

On 01/09/2018 05:00 AM, Will Deacon wrote: > On Mon, Jan 08, 2018 at 08:06:27PM -0800, Jayachandran C wrote: >> On Mon, Jan 08, 2018 at 05:51:00PM +, Will Deacon wrote: >>> On Mon, Jan 08, 2018 at 09:40:17AM -0800, Jayachandran C wrote: On Mon, Jan 08, 2018 at 09:20:09AM +, Marc

Re: [v2,03/11] arm64: Take into account ID_AA64PFR0_EL1.CSV3

On 01/09/2018 05:00 AM, Will Deacon wrote: > On Mon, Jan 08, 2018 at 08:06:27PM -0800, Jayachandran C wrote: >> On Mon, Jan 08, 2018 at 05:51:00PM +, Will Deacon wrote: >>> On Mon, Jan 08, 2018 at 09:40:17AM -0800, Jayachandran C wrote: On Mon, Jan 08, 2018 at 09:20:09AM +, Marc

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/18/2018 12:56 PM, Jayachandran C wrote: > On Thu, Jan 18, 2018 at 01:53:55PM +, Will Deacon wrote: >> Hi JC, >> >> On Tue, Jan 16, 2018 at 03:45:54PM -0800, Jayachandran C wrote: >>> On Tue, Jan 16, 2018 at 04:52:53PM -0500, Jon Masters wrote: >>>&

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/18/2018 12:56 PM, Jayachandran C wrote: > On Thu, Jan 18, 2018 at 01:53:55PM +, Will Deacon wrote: >> Hi JC, >> >> On Tue, Jan 16, 2018 at 03:45:54PM -0800, Jayachandran C wrote: >>> On Tue, Jan 16, 2018 at 04:52:53PM -0500, Jon Masters wrote: >>>&

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/16/2018 06:45 PM, Jayachandran C wrote: > On Tue, Jan 16, 2018 at 04:52:53PM -0500, Jon Masters wrote: >> On 01/09/2018 07:47 AM, Jayachandran C wrote: >> >>> Use PSCI based mitigation for speculative execution attacks targeting >>> the branch predictor. T

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/16/2018 06:45 PM, Jayachandran C wrote: > On Tue, Jan 16, 2018 at 04:52:53PM -0500, Jon Masters wrote: >> On 01/09/2018 07:47 AM, Jayachandran C wrote: >> >>> Use PSCI based mitigation for speculative execution attacks targeting >>> the branch predictor. T

Re: [PATCH 2/6] s390: implement nospec_[load|ptr]

On 01/17/2018 07:41 AM, Jiri Kosina wrote: > On Wed, 17 Jan 2018, Martin Schwidefsky wrote: > >> Implement nospec_load() and nospec_ptr() for s390 with the new >> gmb() barrier between the boundary condition and the load that >> may not be done speculatively. Thanks for the patches, Martin et

Re: [PATCH 2/6] s390: implement nospec_[load|ptr]

On 01/17/2018 07:41 AM, Jiri Kosina wrote: > On Wed, 17 Jan 2018, Martin Schwidefsky wrote: > >> Implement nospec_load() and nospec_ptr() for s390 with the new >> gmb() barrier between the boundary condition and the load that >> may not be done speculatively. Thanks for the patches, Martin et

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/09/2018 07:47 AM, Jayachandran C wrote: > Use PSCI based mitigation for speculative execution attacks targeting > the branch predictor. The approach is similar to the one used for > Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to > test if the firmware supports the

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/09/2018 07:47 AM, Jayachandran C wrote: > Use PSCI based mitigation for speculative execution attacks targeting > the branch predictor. The approach is similar to the one used for > Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to > test if the firmware supports the

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/09/2018 07:47 AM, Jayachandran C wrote: > Use PSCI based mitigation for speculative execution attacks targeting > the branch predictor. The approach is similar to the one used for > Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to > test if the firmware supports the

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

On 01/09/2018 07:47 AM, Jayachandran C wrote: > Use PSCI based mitigation for speculative execution attacks targeting > the branch predictor. The approach is similar to the one used for > Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to > test if the firmware supports the

Re: Improve retpoline for Skylake

On 01/12/2018 05:03 PM, Henrique de Moraes Holschuh wrote: > On Fri, 12 Jan 2018, Andi Kleen wrote: >>> Skylake still loses if it takes an SMI, right? >> >> SMMs are usually rare, especially on servers, and are usually >> not very predictible, and even if you have > > FWIW, a data point: SMIs

Re: Improve retpoline for Skylake

On 01/12/2018 05:03 PM, Henrique de Moraes Holschuh wrote: > On Fri, 12 Jan 2018, Andi Kleen wrote: >>> Skylake still loses if it takes an SMI, right? >> >> SMMs are usually rare, especially on servers, and are usually >> not very predictible, and even if you have > > FWIW, a data point: SMIs

Re: [PATCH 09/11] powerpc/64s: Allow control of RFI flush via sysfs

On 01/09/2018 03:05 AM, Greg KH wrote: > On Tue, Jan 09, 2018 at 01:06:23AM -0500, Jon Masters wrote: >> Knowing that the IBM team was going to post with this sysfs interface, >> our trees contain the rfi_flush file. I mentioned it to some folks on >> this end (because we know

Re: [PATCH 09/11] powerpc/64s: Allow control of RFI flush via sysfs

On 01/09/2018 03:05 AM, Greg KH wrote: > On Tue, Jan 09, 2018 at 01:06:23AM -0500, Jon Masters wrote: >> Knowing that the IBM team was going to post with this sysfs interface, >> our trees contain the rfi_flush file. I mentioned it to some folks on >> this end (because we know

Re: [PATCH 09/11] powerpc/64s: Allow control of RFI flush via sysfs

On 01/08/2018 05:09 PM, Michael Ellerman wrote: > Thomas Gleixner writes: > >> On Tue, 9 Jan 2018, Michael Ellerman wrote: >> >> Sorry, I wasn't aware about your efforts and did not cc you. I've just >> queued a more generic sysfs interface for this whole mess: > > No

Re: [PATCH 09/11] powerpc/64s: Allow control of RFI flush via sysfs

On 01/08/2018 05:09 PM, Michael Ellerman wrote: > Thomas Gleixner writes: > >> On Tue, 9 Jan 2018, Michael Ellerman wrote: >> >> Sorry, I wasn't aware about your efforts and did not cc you. I've just >> queued a more generic sysfs interface for this whole mess: > > No worries. > >>

Re: [PATCH v2 07/11] arm64: Add skeleton to harden the branch predictor against aliasing attacks

On 01/05/2018 08:12 AM, Will Deacon wrote: > Aliasing attacks against CPU branch predictors can allow an attacker to > redirect speculative control flow on some CPUs and potentially divulge > information from one context to another. > > This patch adds initial skeleton code behind a new Kconfig

Re: [PATCH v2 07/11] arm64: Add skeleton to harden the branch predictor against aliasing attacks

On 01/05/2018 08:12 AM, Will Deacon wrote: > Aliasing attacks against CPU branch predictors can allow an attacker to > redirect speculative control flow on some CPUs and potentially divulge > information from one context to another. > > This patch adds initial skeleton code behind a new Kconfig

Re: Avoid speculative indirect calls in kernel

On 01/04/2018 07:54 PM, Thomas Gleixner wrote: > On Thu, 4 Jan 2018, Jon Masters wrote: >> P.S. I've an internal document where I've been tracking "nice to haves" >> for later, and one of them is whether it makes sense to tag binaries as >> "trusted"

Re: Avoid speculative indirect calls in kernel

On 01/04/2018 07:54 PM, Thomas Gleixner wrote: > On Thu, 4 Jan 2018, Jon Masters wrote: >> P.S. I've an internal document where I've been tracking "nice to haves" >> for later, and one of them is whether it makes sense to tag binaries as >> "trusted"

Re: Avoid speculative indirect calls in kernel

On 01/04/2018 02:57 PM, Jon Masters wrote: > + Jeff Law, Nick Clifton > > On 01/04/2018 03:20 AM, Woodhouse, David wrote: >> On Thu, 2018-01-04 at 03:11 +0100, Paolo Bonzini wrote: >>> On 04/01/2018 02:59, Alan Cox wrote: >>>>> But then, exactly because

Re: Avoid speculative indirect calls in kernel

On 01/04/2018 02:57 PM, Jon Masters wrote: > + Jeff Law, Nick Clifton > > On 01/04/2018 03:20 AM, Woodhouse, David wrote: >> On Thu, 2018-01-04 at 03:11 +0100, Paolo Bonzini wrote: >>> On 04/01/2018 02:59, Alan Cox wrote: >>>>> But then, exactly because

Re: Avoid speculative indirect calls in kernel

On 01/04/2018 01:33 PM, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 3:26 AM, Pavel Machek wrote: >> On Wed 2018-01-03 15:51:35, Linus Torvalds wrote: >>> >>> A *competent* CPU engineer would fix this by making sure speculation >>> doesn't happen across protection domains. Maybe

Re: Avoid speculative indirect calls in kernel

On 01/04/2018 01:33 PM, Linus Torvalds wrote: > On Thu, Jan 4, 2018 at 3:26 AM, Pavel Machek wrote: >> On Wed 2018-01-03 15:51:35, Linus Torvalds wrote: >>> >>> A *competent* CPU engineer would fix this by making sure speculation >>> doesn't happen across protection domains. Maybe even a L1 I$

Re: Avoid speculative indirect calls in kernel

+ Jeff Law, Nick Clifton On 01/04/2018 03:20 AM, Woodhouse, David wrote: > On Thu, 2018-01-04 at 03:11 +0100, Paolo Bonzini wrote: >> On 04/01/2018 02:59, Alan Cox wrote: But then, exactly because the retpoline approach adds quite some cruft and leaves something to be desired, why even

Re: Avoid speculative indirect calls in kernel

+ Jeff Law, Nick Clifton On 01/04/2018 03:20 AM, Woodhouse, David wrote: > On Thu, 2018-01-04 at 03:11 +0100, Paolo Bonzini wrote: >> On 04/01/2018 02:59, Alan Cox wrote: But then, exactly because the retpoline approach adds quite some cruft and leaves something to be desired, why even

Re: [PATCH 0/2] acpi, x86: Add SPCR table support

On 12/08/2017 09:29 AM, Prarit Bhargava wrote: > If I disable "Serial Port Console Debug" in my BIOS I still see the SPCR > configured: > > [root@prarit-lab ~]# dmesg | grep SPCR > [0.00] ACPI: SPCR 0x69031000 50 (v01 > ) > > AFAICT the SPCR is always

Re: [PATCH 0/2] acpi, x86: Add SPCR table support

On 12/08/2017 09:29 AM, Prarit Bhargava wrote: > If I disable "Serial Port Console Debug" in my BIOS I still see the SPCR > configured: > > [root@prarit-lab ~]# dmesg | grep SPCR > [0.00] ACPI: SPCR 0x69031000 50 (v01 > ) > > AFAICT the SPCR is always

Re: [PATCH] x86/microcode/AMD: Add support for fam17h microcode loading

# 4.1.x > Signed-off-by: Tom Lendacky <thomas.lenda...@amd.com> Tested-by: Jon Masters <j...@redhat.com> -- Computer Architect | Sent from my Fedora powered laptop

Re: [PATCH] x86/microcode/AMD: Add support for fam17h microcode loading

f-by: Tom Lendacky Tested-by: Jon Masters -- Computer Architect | Sent from my Fedora powered laptop

Re: [PATCH v4 00/12] arm+arm64: vdso unification to lib/vdso/

On 10/31/2017 02:30 PM, Mark Salyzyn wrote: > Take an effort to recode the arm64 vdso code from assembler to C > previously submitted by Andrew Pinski , rework > it for use in both arm and arm64, overlapping any optimizations > for each architecture. But instead of landing it

Re: [PATCH v4 00/12] arm+arm64: vdso unification to lib/vdso/

On 10/31/2017 02:30 PM, Mark Salyzyn wrote: > Take an effort to recode the arm64 vdso code from assembler to C > previously submitted by Andrew Pinski , rework > it for use in both arm and arm64, overlapping any optimizations > for each architecture. But instead of landing it in arm64, land the >

Re: [PATCH v3 0/7] Support PPTT for ARM64

On 10/12/2017 03:48 PM, Jeremy Linton wrote: > ACPI 6.2 adds the Processor Properties Topology Table (PPTT), which is > used to describe the processor and cache topology. Ideally it is > used to extend/override information provided by the hardware, but > right now ARM64 is entirely dependent on

Re: [PATCH v3 0/7] Support PPTT for ARM64

On 10/12/2017 03:48 PM, Jeremy Linton wrote: > ACPI 6.2 adds the Processor Properties Topology Table (PPTT), which is > used to describe the processor and cache topology. Ideally it is > used to extend/override information provided by the hardware, but > right now ARM64 is entirely dependent on

Re: [PATCH] ahci: Add support for Cavium's fifth generation SATA controller

On 10/17/2017 02:58 AM, Christoph Hellwig wrote: > On Tue, Oct 10, 2017 at 10:37:51PM -0700, Radha Mohan Chintakuntla wrote: >> From: Radha Mohan Chintakuntla >> >> This patch adds support for Cavium's fifth generation SATA controller. >> It is an on-chip controller and

Re: [PATCH] ahci: Add support for Cavium's fifth generation SATA controller

On 10/17/2017 02:58 AM, Christoph Hellwig wrote: > On Tue, Oct 10, 2017 at 10:37:51PM -0700, Radha Mohan Chintakuntla wrote: >> From: Radha Mohan Chintakuntla >> >> This patch adds support for Cavium's fifth generation SATA controller. >> It is an on-chip controller and complies with AHCI 1.3.1.

Cleaning up non-standard PCIe ECAM on Arm servers

On 10/06/2017 12:39 PM, Ard Biesheuvel wrote: > Some implementations of the Synopsys DesignWare PCIe controller implement > a so-called ECAM shift mode, which allows a static memory window to be > configured that covers the configuration space of the entire bus range. Side note that we gave a

Cleaning up non-standard PCIe ECAM on Arm servers

On 10/06/2017 12:39 PM, Ard Biesheuvel wrote: > Some implementations of the Synopsys DesignWare PCIe controller implement > a so-called ECAM shift mode, which allows a static memory window to be > configured that covers the configuration space of the entire bus range. Side note that we gave a

Re: [PATCH 0/3] arm64: cpuinfo: make /proc/cpuinfo more human-readable

On 10/20/2017 01:24 PM, Jon Masters wrote: > 1). The first thing people do when they get an Arm server is to cat > /proc/cpuinfo. They then come complaining that it's not like x86. They > can't get the output their looking for and this results in bug filing, > and countless hours on

  1   2   3   4   5   6   7   8   9   >