Hi Will,
On 03/27/2018 12:36 PM, Will Deacon wrote:
> Hi Shanker,
>
> On Tue, Mar 27, 2018 at 09:53:16AM -0500, Shanker Donthineni wrote:
>> On 03/27/2018 06:34 AM, Robin Murphy wrote:
>>> On 27/03/18 04:21, Philip Elcan wrote:
>>>> Several of the bits of th
Hi Will,
On 03/27/2018 12:36 PM, Will Deacon wrote:
> Hi Shanker,
>
> On Tue, Mar 27, 2018 at 09:53:16AM -0500, Shanker Donthineni wrote:
>> On 03/27/2018 06:34 AM, Robin Murphy wrote:
>>> On 27/03/18 04:21, Philip Elcan wrote:
>>>> Several of the bits of th
make this a static inline function rather than a macro,
> since it doesn't need to do any wacky type-dodging, but either way the
> overall change now looks appropriate;
>
> Acked-by: Robin Murphy <robin.mur...@arm.com>
>
Tested-by: Shanker Donthineni <shank...@co
c inline function rather than a macro,
> since it doesn't need to do any wacky type-dodging, but either way the
> overall change now looks appropriate;
>
> Acked-by: Robin Murphy
>
Tested-by: Shanker Donthineni
> Thanks,
> Robin.
>
>> +
>> /*
>> * TL
Hi Marc,
On 03/22/2018 10:51 AM, Marc Zyngier wrote:
> On 22/03/18 01:58, Shanker Donthineni wrote:
>> The definition of the GICR_CTLR.RWP control bit was expanded to indicate
>> status of changing GICR_CTLR.EnableLPI from 1 to 0 is being in progress
>> or completed.
Hi Marc,
On 03/22/2018 10:51 AM, Marc Zyngier wrote:
> On 22/03/18 01:58, Shanker Donthineni wrote:
>> The definition of the GICR_CTLR.RWP control bit was expanded to indicate
>> status of changing GICR_CTLR.EnableLPI from 1 to 0 is being in progress
>> or completed.
and/or
GICR_PROPBASER, otherwise behavior is UNPREDICTABLE.
Signed-off-by: Shanker Donthineni <shank...@codeaurora.org>
---
Changes since v2:
-Revert readl_relaxed_poll() usage since it's not usable in GICv3 probe().
-Changes to pr_xxx messages.
Changes since v1:
-Moved LPI disable code to a seperate fu
and/or
GICR_PROPBASER, otherwise behavior is UNPREDICTABLE.
Signed-off-by: Shanker Donthineni
---
Changes since v2:
-Revert readl_relaxed_poll() usage since it's not usable in GICv3 probe().
-Changes to pr_xxx messages.
Changes since v1:
-Moved LPI disable code to a seperate function as Marc suggested
Hi Marc,
On 03/17/2018 12:13 PM, Marc Zyngier wrote:
> On Sat, 17 Mar 2018 16:11:06 +,
> Shanker Donthineni wrote:
>>
>> Hi Marc,
>>
>> On 03/17/2018 08:34 AM, Marc Zyngier wrote:
>>> On Thu, 15 Mar 2018 09:31:27 -0500
>>> Sh
Hi Marc,
On 03/17/2018 12:13 PM, Marc Zyngier wrote:
> On Sat, 17 Mar 2018 16:11:06 +,
> Shanker Donthineni wrote:
>>
>> Hi Marc,
>>
>> On 03/17/2018 08:34 AM, Marc Zyngier wrote:
>>> On Thu, 15 Mar 2018 09:31:27 -0500
>>> Sh
Hi Marc,
On 03/17/2018 08:34 AM, Marc Zyngier wrote:
> On Thu, 15 Mar 2018 09:31:27 -0500
> Shanker Donthineni <shank...@codeaurora.org> wrote:
>
>> The definition of the GICR_CTLR.RWP control bit was expanded to indicate
>> status of changing GICR_CTLR.EnableLPI from
Hi Marc,
On 03/17/2018 08:34 AM, Marc Zyngier wrote:
> On Thu, 15 Mar 2018 09:31:27 -0500
> Shanker Donthineni wrote:
>
>> The definition of the GICR_CTLR.RWP control bit was expanded to indicate
>> status of changing GICR_CTLR.EnableLPI from 1 to 0 is being in pro
; GICD_TYPER_LPIS);
> + return !!(readl_relaxed(gic_data.dist_base + GICD_TYPER) &
> GICD_TYPER_LPIS) && !gicv3_nolpi;
Thanks for this patch series especially for KDUMP case. It would be nice if we
disable GIC-ITS and
GICR-LPI functionality completely to avoid in flig
+ return !!(readl_relaxed(gic_data.dist_base + GICD_TYPER) &
> GICD_TYPER_LPIS) && !gicv3_nolpi;
Thanks for this patch series especially for KDUMP case. It would be nice if we
disable GIC-ITS and
GICR-LPI functionality completely to avoid in flight LPIs which were triggered
b
and/or
GICR_PROPBASER, otherwise behavior is UNPREDICTABLE.
Signed-off-by: Shanker Donthineni <shank...@codeaurora.org>
---
Changes since v1:
-Moved LPI disable code to a seperate function as Marc suggested.
-Mark's suggestion to use readl_relaxed_poll_timeout() helper functions.
drivers/irqchip/irq-
and/or
GICR_PROPBASER, otherwise behavior is UNPREDICTABLE.
Signed-off-by: Shanker Donthineni
---
Changes since v1:
-Moved LPI disable code to a seperate function as Marc suggested.
-Mark's suggestion to use readl_relaxed_poll_timeout() helper functions.
drivers/irqchip/irq-gic-v3-its.c | 66
) - 1;
>> +pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
>> #endif
>> continue;
>> }
>> --
>> 2.15.1
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Shanker Donthineni
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux
Foundation Collaborative Project.
_nr_pages-1)) - 1;
>> +pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
>> #endif
>> continue;
>> }
>> --
>> 2.15.1
>>
>>
>> ___
>> linux-arm
Hi Marc,
On 03/14/2018 02:41 AM, Marc Zyngier wrote:
> Hi Shanker,
>
> On Wed, 14 Mar 2018 00:50:01 +,
> Shanker Donthineni wrote:
>>
>> The definition of the GICR_CTLR.RWP control bit was expanded to indicate
>> status of changing GICR_CTLR.EnableLPI fr
Hi Marc,
On 03/14/2018 02:41 AM, Marc Zyngier wrote:
> Hi Shanker,
>
> On Wed, 14 Mar 2018 00:50:01 +,
> Shanker Donthineni wrote:
>>
>> The definition of the GICR_CTLR.RWP control bit was expanded to indicate
>> status of changing GICR_CTLR.EnableLPI fr
and/or
GICR_PROPBASER, otherwise behavior is UNPREDICTABLE.
Signed-off-by: Shanker Donthineni <shank...@codeaurora.org>
---
drivers/irqchip/irq-gic-v3-its.c | 30 +++---
include/linux/irqchip/arm-gic-v3.h | 1 +
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/d
and/or
GICR_PROPBASER, otherwise behavior is UNPREDICTABLE.
Signed-off-by: Shanker Donthineni
---
drivers/irqchip/irq-gic-v3-its.c | 30 +++---
include/linux/irqchip/arm-gic-v3.h | 1 +
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b
Hi Will,
On 03/09/2018 07:48 AM, Will Deacon wrote:
> Hi SHanker,
>
> On Mon, Mar 05, 2018 at 11:06:43AM -0600, Shanker Donthineni wrote:
>> The function SMCCC_ARCH_WORKAROUND_1 was introduced as part of SMC
>> V1.1 Calling Convention to mitigate CVE-2017-5715. This patch
Hi Will,
On 03/09/2018 07:48 AM, Will Deacon wrote:
> Hi SHanker,
>
> On Mon, Mar 05, 2018 at 11:06:43AM -0600, Shanker Donthineni wrote:
>> The function SMCCC_ARCH_WORKAROUND_1 was introduced as part of SMC
>> V1.1 Calling Convention to mitigate CVE-2017-5715. This patch
Hi Will,
On 03/06/2018 09:25 AM, Will Deacon wrote:
> On Mon, Mar 05, 2018 at 12:03:33PM -0600, Shanker Donthineni wrote:
>> On 03/05/2018 11:15 AM, Will Deacon wrote:
>>> On Mon, Mar 05, 2018 at 10:57:58AM -0600, Shanker Donthineni wrote:
>>>> On 03/05/20
Hi Will,
On 03/06/2018 09:25 AM, Will Deacon wrote:
> On Mon, Mar 05, 2018 at 12:03:33PM -0600, Shanker Donthineni wrote:
>> On 03/05/2018 11:15 AM, Will Deacon wrote:
>>> On Mon, Mar 05, 2018 at 10:57:58AM -0600, Shanker Donthineni wrote:
>>>> On 03/05/20
org>
Signed-off-by: Shanker Donthineni <shank...@codeaurora.org>
---
Changes since v6:
-Both I-Cache and D-Cache changes are symmetric as Will suggested.
-Remove Kconfig option.
-Patch __flush_icache_all().
Changes since v5:
-Addressed Mark's review comments.
Changes since v4:
-Moved patc
ired for
instruction to data coherence, unless CLIDR_EL1.LoC == 0b000
or (CLIDR_EL1.LoUIS == 0b000 && CLIDR_EL1.LoUU == 0b000).
1: Data cache clean to the point of unification is not required
for instruction to data coherence.
Co-authored-by: Philip Elcan
Signed-off-by: Shanke
Hi Will,
On 03/06/2018 12:48 PM, Shanker Donthineni wrote:
> Hi Will,
>
> On 03/06/2018 09:23 AM, Will Deacon wrote:
>> Hi Shanker,
>>
>> On Tue, Mar 06, 2018 at 08:47:27AM -0600, Shanker Donthineni wrote:
>>> On 03/06/2018 07:44 AM, Will Deacon wrote:
>
Hi Will,
On 03/06/2018 12:48 PM, Shanker Donthineni wrote:
> Hi Will,
>
> On 03/06/2018 09:23 AM, Will Deacon wrote:
>> Hi Shanker,
>>
>> On Tue, Mar 06, 2018 at 08:47:27AM -0600, Shanker Donthineni wrote:
>>> On 03/06/2018 07:44 AM, Will Deacon wrote:
>
Hi Will,
On 03/06/2018 09:23 AM, Will Deacon wrote:
> Hi Shanker,
>
> On Tue, Mar 06, 2018 at 08:47:27AM -0600, Shanker Donthineni wrote:
>> On 03/06/2018 07:44 AM, Will Deacon wrote:
>>> I think this is a slight asymmetry with the code for the I-side. On
Hi Will,
On 03/06/2018 09:23 AM, Will Deacon wrote:
> Hi Shanker,
>
> On Tue, Mar 06, 2018 at 08:47:27AM -0600, Shanker Donthineni wrote:
>> On 03/06/2018 07:44 AM, Will Deacon wrote:
>>> I think this is a slight asymmetry with the code for the I-side. On
Hi Will
On 03/06/2018 07:44 AM, Will Deacon wrote:
> Hi Shanker,
>
> On Wed, Feb 28, 2018 at 10:14:00PM -0600, Shanker Donthineni wrote:
>> The DCache clean & ICache invalidation requirements for instructions
>> to be data coherence are discoverable thro
Hi Will
On 03/06/2018 07:44 AM, Will Deacon wrote:
> Hi Shanker,
>
> On Wed, Feb 28, 2018 at 10:14:00PM -0600, Shanker Donthineni wrote:
>> The DCache clean & ICache invalidation requirements for instructions
>> to be data coherence are discoverable thro
Hi Will,
On 03/05/2018 11:15 AM, Will Deacon wrote:
> On Mon, Mar 05, 2018 at 10:57:58AM -0600, Shanker Donthineni wrote:
>> Hi Will,
>>
>> On 03/05/2018 09:56 AM, Will Deacon wrote:
>>> Hi Shanker,
>>>
>>> On Fri, Mar 02, 2018 at 03:50:18PM -0
Hi Will,
On 03/05/2018 11:15 AM, Will Deacon wrote:
> On Mon, Mar 05, 2018 at 10:57:58AM -0600, Shanker Donthineni wrote:
>> Hi Will,
>>
>> On 03/05/2018 09:56 AM, Will Deacon wrote:
>>> Hi Shanker,
>>>
>>> On Fri, Mar 02, 2018 at 03:50:18PM -0
The function SMCCC_ARCH_WORKAROUND_1 was introduced as part of SMC
V1.1 Calling Convention to mitigate CVE-2017-5715. This patch uses
the standard call SMCCC_ARCH_WORKAROUND_1 for Falkor chips instead
of Silicon provider service ID 0xC2001700.
Signed-off-by: Shanker Donthineni <sh
The function SMCCC_ARCH_WORKAROUND_1 was introduced as part of SMC
V1.1 Calling Convention to mitigate CVE-2017-5715. This patch uses
the standard call SMCCC_ARCH_WORKAROUND_1 for Falkor chips instead
of Silicon provider service ID 0xC2001700.
Signed-off-by: Shanker Donthineni
---
Chnages since
Hi Will,
On 03/05/2018 09:56 AM, Will Deacon wrote:
> Hi Shanker,
>
> On Fri, Mar 02, 2018 at 03:50:18PM -0600, Shanker Donthineni wrote:
>> The function SMCCC_ARCH_WORKAROUND_1 was introduced as part of SMC
>> V1.1 Calling Convention to mitigate CVE-2017-5715. This patch
Hi Will,
On 03/05/2018 09:56 AM, Will Deacon wrote:
> Hi Shanker,
>
> On Fri, Mar 02, 2018 at 03:50:18PM -0600, Shanker Donthineni wrote:
>> The function SMCCC_ARCH_WORKAROUND_1 was introduced as part of SMC
>> V1.1 Calling Convention to mitigate CVE-2017-5715. This patch
The function SMCCC_ARCH_WORKAROUND_1 was introduced as part of SMC
V1.1 Calling Convention to mitigate CVE-2017-5715. This patch uses
the standard call SMCCC_ARCH_WORKAROUND_1 for Falkor chips instead
of Silicon provider service ID 0xC2001700.
Signed-off-by: Shanker Donthineni <sh
The function SMCCC_ARCH_WORKAROUND_1 was introduced as part of SMC
V1.1 Calling Convention to mitigate CVE-2017-5715. This patch uses
the standard call SMCCC_ARCH_WORKAROUND_1 for Falkor chips instead
of Silicon provider service ID 0xC2001700.
Signed-off-by: Shanker Donthineni
---
arch/arm64
org>
Signed-off-by: Shanker Donthineni <shank...@codeaurora.org>
---
Changes since v5:
-Addressed Mark's review comments.
Changes since v4:
-Moved patching ARM64_HAS_CACHE_DIC inside invalidate_icache_by_line
-Removed 'dsb ishst' for ARM64_HAS_CACHE_DIC as Mark suggested.
Changes since v
ired for
instruction to data coherence, unless CLIDR_EL1.LoC == 0b000
or (CLIDR_EL1.LoUIS == 0b000 && CLIDR_EL1.LoUU == 0b000).
1: Data cache clean to the point of unification is not required
for instruction to data coherence.
Co-authored-by: Philip Elcan
Signed-off-by: Shanke
org>
Signed-off-by: Shanker Donthineni <shank...@codeaurora.org>
---
Changes since v4:
-Moved patching ARM64_HAS_CACHE_DIC inside invalidate_icache_by_line
-Removed 'dsb ishst' for ARM64_HAS_CACHE_DIC as Mark suggested.
Changes since v3:
-Added preprocessor guard CONFIG_xxx to code snippe
ired for
instruction to data coherence, unless CLIDR_EL1.LoC == 0b000
or (CLIDR_EL1.LoUIS == 0b000 && CLIDR_EL1.LoUU == 0b000).
1: Data cache clean to the point of unification is not required
for instruction to data coherence.
Signed-off-by: Philip Elcan
Signed-off-by: Shanke
org>
Signed-off-by: Shanker Donthineni <shank...@codeaurora.org>
---
Changes since v3:
-Added preprocessor guard CONFIG_xxx to code snippets in cache.S
-Changed barrier attributes from ISH to ISHST.
Changes since v2:
-Included barriers, DSB/ISB with DIC set, and DSB with IDC set.
-Single
ired for
instruction to data coherence, unless CLIDR_EL1.LoC == 0b000
or (CLIDR_EL1.LoUIS == 0b000 && CLIDR_EL1.LoUU == 0b000).
1: Data cache clean to the point of unification is not required
for instruction to data coherence.
Signed-off-by: Philip Elcan
Signed-off-by: Shanke
Hi Mark,
On 02/21/2018 09:09 AM, Mark Rutland wrote:
> On Wed, Feb 21, 2018 at 07:49:06AM -0600, Shanker Donthineni wrote:
>> The DCache clean & ICache invalidation requirements for instructions
>> to be data coherence are discoverable through new fields in CTR_EL0.
>>
Hi Mark,
On 02/21/2018 09:09 AM, Mark Rutland wrote:
> On Wed, Feb 21, 2018 at 07:49:06AM -0600, Shanker Donthineni wrote:
>> The DCache clean & ICache invalidation requirements for instructions
>> to be data coherence are discoverable through new fields in CTR_EL0.
>>
org>
Signed-off-by: Shanker Donthineni <shank...@codeaurora.org>
---
Changes since v2:
-Included barriers, DSB/ISB with DIC set, and DSB with IDC set.
-Single Kconfig option.
Changes since v1:
-Reworded commit text.
-Used the alternatives framework as Catalin suggested.
ired for
instruction to data coherence, unless CLIDR_EL1.LoC == 0b000
or (CLIDR_EL1.LoUIS == 0b000 && CLIDR_EL1.LoUU == 0b000).
1: Data cache clean to the point of unification is not required
for instruction to data coherence.
Signed-off-by: Philip Elcan
Signed-off-by: Shanke
Hi Catalin,
On 02/21/2018 05:12 AM, Catalin Marinas wrote:
> On Mon, Feb 19, 2018 at 08:59:06PM -0600, Shanker Donthineni wrote:
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index f55fe5b..4061210 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kco
Hi Catalin,
On 02/21/2018 05:12 AM, Catalin Marinas wrote:
> On Mon, Feb 19, 2018 at 08:59:06PM -0600, Shanker Donthineni wrote:
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index f55fe5b..4061210 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kco
org>
Signed-off-by: Shanker Donthineni <shank...@codeaurora.org>
---
Changes since v1:
-Reworded commit text.
-Used the alternatives framework as Catalin suggested.
-Rebased on top of https://patchwork.kernel.org/patch/10227927/
arch/arm64/Kconfig | 21 +++
arch/a
ired for
instruction to data coherence, unless CLIDR_EL1.LoC == 0b000
or (CLIDR_EL1.LoUIS == 0b000 && CLIDR_EL1.LoUU == 0b000).
1: Data cache clean to the point of unification is not required
for instruction to data coherence.
Signed-off-by: Philip Elcan
Signed-off-by: Shanke
Thanks Catalin for your comments.
On 02/19/2018 11:18 AM, Catalin Marinas wrote:
> On Mon, Feb 19, 2018 at 10:35:30AM -0600, Shanker Donthineni wrote:
>> On 02/19/2018 08:38 AM, Catalin Marinas wrote:
>>> On the patch, I'd rather have an alternative framework entry for no V
Thanks Catalin for your comments.
On 02/19/2018 11:18 AM, Catalin Marinas wrote:
> On Mon, Feb 19, 2018 at 10:35:30AM -0600, Shanker Donthineni wrote:
>> On 02/19/2018 08:38 AM, Catalin Marinas wrote:
>>> On the patch, I'd rather have an alternative framework entry for no V
Hi Will,
On 02/19/2018 08:43 AM, Will Deacon wrote:
> Hi Shanker,
>
> On Fri, Feb 16, 2018 at 06:57:46PM -0600, Shanker Donthineni wrote:
>> Two point of unification cache maintenance operations 'DC CVAU' and
>> 'IC IVAU' are optional for implementors as per ARMv8 specifi
Hi Will,
On 02/19/2018 08:43 AM, Will Deacon wrote:
> Hi Shanker,
>
> On Fri, Feb 16, 2018 at 06:57:46PM -0600, Shanker Donthineni wrote:
>> Two point of unification cache maintenance operations 'DC CVAU' and
>> 'IC IVAU' are optional for implementors as per ARMv8 specifi
Hi Catalin,
On 02/19/2018 08:38 AM, Catalin Marinas wrote:
> On Fri, Feb 16, 2018 at 06:57:46PM -0600, Shanker Donthineni wrote:
>> Two point of unification cache maintenance operations 'DC CVAU' and
>> 'IC IVAU' are optional for implementors as per ARMv8 specification.
>&
Hi Catalin,
On 02/19/2018 08:38 AM, Catalin Marinas wrote:
> On Fri, Feb 16, 2018 at 06:57:46PM -0600, Shanker Donthineni wrote:
>> Two point of unification cache maintenance operations 'DC CVAU' and
>> 'IC IVAU' are optional for implementors as per ARMv8 specification.
>&
.
— CNTVCT is read from Non-secure EL0.
So, no need to zero CNTVOFF_EL2/CNTVOFF for VHE case.
Signed-off-by: Shanker Donthineni <shank...@codeaurora.org>
---
virt/kvm/arm/arch_timer.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/k
.
— CNTVCT is read from Non-secure EL0.
So, no need to zero CNTVOFF_EL2/CNTVOFF for VHE case.
Signed-off-by: Shanker Donthineni
---
virt/kvm/arm/arch_timer.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 70268c0
== 0b000
or (CLIDR_EL1.LoUIS == 0b000 && CLIDR_EL1.LoUU == 0b000).
1: Data cache clean to the point of unification is not required
for instruction to data coherence.
Signed-off-by: Philip Elcan <pel...@codeaurora.org>
Signed-off-by: Shanker Donthineni <shank...@codeaurora.org
== 0b000
or (CLIDR_EL1.LoUIS == 0b000 && CLIDR_EL1.LoUU == 0b000).
1: Data cache clean to the point of unification is not required
for instruction to data coherence.
Signed-off-by: Philip Elcan
Signed-off-by: Shanker Donthineni
---
arch/arm64/include/asm/assemble
References to CPU part number MIDR_QCOM_FALKOR were dropped from the
mailing list patch due to mainline/arm64 branch dependency. So this
patch adds the missing part number.
Fixes: ec82b567a74f ("arm64: Implement branch predictor hardening for Falkor")
Signed-off-by: Shanker Donthin
References to CPU part number MIDR_QCOM_FALKOR were dropped from the
mailing list patch due to mainline/arm64 branch dependency. So this
patch adds the missing part number.
Fixes: ec82b567a74f ("arm64: Implement branch predictor hardening for Falkor")
Signed-off-by: Shanker Donthineni
Hi Will, Thanks for your quick reply.
On 02/01/2018 04:33 AM, Will Deacon wrote:
> Hi Shanker,
>
> On Wed, Jan 31, 2018 at 06:03:42PM -0600, Shanker Donthineni wrote:
>> A DMB instruction can be used to ensure the relative order of only
>> memory accesses before and aft
Hi Will, Thanks for your quick reply.
On 02/01/2018 04:33 AM, Will Deacon wrote:
> Hi Shanker,
>
> On Wed, Jan 31, 2018 at 06:03:42PM -0600, Shanker Donthineni wrote:
>> A DMB instruction can be used to ensure the relative order of only
>> memory accesses before and aft
ensures that no instructions that appear in program
order after the DSB instruction, can execute until the DSB instruction
has completed.
Signed-off-by: Shanker Donthineni <shank...@codeaurora.org>
---
drivers/irqchip/irq-gic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
ensures that no instructions that appear in program
order after the DSB instruction, can execute until the DSB instruction
has completed.
Signed-off-by: Shanker Donthineni
---
drivers/irqchip/irq-gic-v3.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic
/git/next/linux-next.git/commit/arch/arm64?h=next-20180112=ec82b567a74fbdffdf418d4bb381d55f6a9096af
[v2] https://www.spinics.net/lists/arm-kernel/msg627364.html
Thanks,
Shanker
On 01/08/2018 11:32 AM, Will Deacon wrote:
> From: Shanker Donthineni <shank...@codeaurora.org>
>
> Falkor
/git/next/linux-next.git/commit/arch/arm64?h=next-20180112=ec82b567a74fbdffdf418d4bb381d55f6a9096af
[v2] https://www.spinics.net/lists/arm-kernel/msg627364.html
Thanks,
Shanker
On 01/08/2018 11:32 AM, Will Deacon wrote:
> From: Shanker Donthineni
>
> Falkor is susceptible to branch
able in upstream v4.15-rc7
branch. Please merge v2 patch.
On 01/08/2018 01:10 PM, Shanker Donthineni wrote:
> Hi Will,
>
> On 01/08/2018 12:44 PM, Will Deacon wrote:
>> On Mon, Jan 08, 2018 at 05:09:33PM +, Will Deacon wrote:
>>> On Fri, Jan 05, 2018 at 02:28:59PM -06
able in upstream v4.15-rc7
branch. Please merge v2 patch.
On 01/08/2018 01:10 PM, Shanker Donthineni wrote:
> Hi Will,
>
> On 01/08/2018 12:44 PM, Will Deacon wrote:
>> On Mon, Jan 08, 2018 at 05:09:33PM +, Will Deacon wrote:
>>> On Fri, Jan 05, 2018 at 02:28:59PM -06
Falkor is susceptible to branch predictor aliasing and can
theoretically be attacked by malicious code. This patch
implements a mitigation for these attacks, preventing any
malicious entries from affecting other victim contexts.
Signed-off-by: Shanker Donthineni <shank...@codeaurora.
Falkor is susceptible to branch predictor aliasing and can
theoretically be attacked by malicious code. This patch
implements a mitigation for these attacks, preventing any
malicious entries from affecting other victim contexts.
Signed-off-by: Shanker Donthineni
---
Changes since v1:
Corrected
-by: Shanker Donthineni <shank...@codeaurora.org>
Signed-off-by: Will Deacon <will.dea...@arm.com>
---
This patch is availble at
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64?h=v4.15-rc7=c622cc013cece073722592cff1ac6643a33b1622
arch/arm64/include/a
-by: Shanker Donthineni
Signed-off-by: Will Deacon
---
This patch is availble at
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64?h=v4.15-rc7=c622cc013cece073722592cff1ac6643a33b1622
arch/arm64/include/asm/cputype.h | 2 ++
1 file changed, 2 insertions(+)
diff
Hi Will,
On 01/08/2018 12:44 PM, Will Deacon wrote:
> On Mon, Jan 08, 2018 at 05:09:33PM +, Will Deacon wrote:
>> On Fri, Jan 05, 2018 at 02:28:59PM -0600, Shanker Donthineni wrote:
>>> Falkor is susceptible to branch predictor aliasing and can
>>> theoretically be
Hi Will,
On 01/08/2018 12:44 PM, Will Deacon wrote:
> On Mon, Jan 08, 2018 at 05:09:33PM +, Will Deacon wrote:
>> On Fri, Jan 05, 2018 at 02:28:59PM -0600, Shanker Donthineni wrote:
>>> Falkor is susceptible to branch predictor aliasing and can
>>> theoretically be
Hi Andrew,
On 01/08/2018 03:28 AM, Andrew Jones wrote:
> Hi Shanker,
>
> On Fri, Jan 05, 2018 at 02:28:59PM -0600, Shanker Donthineni wrote:
> ...
>> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
>> index cb0fb37..daf53a5 100644
&g
Hi Andrew,
On 01/08/2018 03:28 AM, Andrew Jones wrote:
> Hi Shanker,
>
> On Fri, Jan 05, 2018 at 02:28:59PM -0600, Shanker Donthineni wrote:
> ...
>> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
>> index cb0fb37..daf53a5 100644
&g
Falkor is susceptible to branch predictor aliasing and can
theoretically be attacked by malicious code. This patch
implements a mitigation for these attacks, preventing any
malicious entries from affecting other victim contexts.
Signed-off-by: Shanker Donthineni <shank...@codeaurora.
Falkor is susceptible to branch predictor aliasing and can
theoretically be attacked by malicious code. This patch
implements a mitigation for these attacks, preventing any
malicious entries from affecting other victim contexts.
Signed-off-by: Shanker Donthineni
---
This patch has been verified
-by: Shanker Donthineni <shank...@codeaurora.org>
---
arch/arm64/include/asm/cputype.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 235e77d..cbf08d7 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch
-by: Shanker Donthineni
---
arch/arm64/include/asm/cputype.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 235e77d..cbf08d7 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -91,6
to 0 when HCR_EL2[VM] has a value of 1).
To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
Signed-off-by: Shanker Donthineni <shank...@codeaurora.org>
---
Changes since v3:
Rebased to kernel v4.
to 0 when HCR_EL2[VM] has a value of 1).
To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
Signed-off-by: Shanker Donthineni
---
Changes since v3:
Rebased to kernel v4.15-rc3 and removed the alternatives
Thanks Mark, I'll post v5 patch without alternatives.
On 12/11/2017 04:45 AM, Mark Rutland wrote:
> Hi,
>
> On Sun, Dec 10, 2017 at 08:03:43PM -0600, Shanker Donthineni wrote:
>> +/**
>> + * Errata workaround prior to disable MMU. Insert an ISB immediately prior
>&g
Thanks Mark, I'll post v5 patch without alternatives.
On 12/11/2017 04:45 AM, Mark Rutland wrote:
> Hi,
>
> On Sun, Dec 10, 2017 at 08:03:43PM -0600, Shanker Donthineni wrote:
>> +/**
>> + * Errata workaround prior to disable MMU. Insert an ISB immediately prior
>&g
Hi Will,
I tested v2 patch series on Centriq2400 server platform successfully, no
regression so far. And also
we applied internal patches on top of the branch "kpti" and verified kaiser
feature.
Tested-by: Shanker Donthineni <shank...@codeaurora.org>
--
Shanker Don
Hi Will,
I tested v2 patch series on Centriq2400 server platform successfully, no
regression so far. And also
we applied internal patches on top of the branch "kpti" and verified kaiser
feature.
Tested-by: Shanker Donthineni
--
Shanker Donthineni
Qualcomm Datacenter Technol
to 0 when HCR_EL2[VM] has a value of 1).
To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
Signed-off-by: Shanker Donthineni <shank...@codeaurora.org>
---
Changes since v3:
Rebased to kernel v4.
to 0 when HCR_EL2[VM] has a value of 1).
To avoid the errant behavior, software must execute an ISB immediately
prior to executing the MSR that will change SCTLR_ELn[M] from 1 to 0.
Signed-off-by: Shanker Donthineni
---
Changes since v3:
Rebased to kernel v4.15-rc1.
Changes since v2:
Repost
-by: Shanker Donthineni <shank...@codeaurora.org>
---
arch/arm64/include/asm/cputype.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 235e77d..cbf08d7 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch
-by: Shanker Donthineni
---
arch/arm64/include/asm/cputype.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 235e77d..cbf08d7 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -91,6
Hi Marc,
I messed-up patch contents please disregard this one and review v4 patch.
[v4] irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry
https://patchwork.kernel.org/patch/10093653/
--
Shanker Donthineni
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Hi Marc,
I messed-up patch contents please disregard this one and review v4 patch.
[v4] irqchip/gic-v3: Fix the driver probe() fail due to disabled GICC entry
https://patchwork.kernel.org/patch/10093653/
--
Shanker Donthineni
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
1 - 100 of 494 matches
Mail list logo
