[RFC/RFT PATCH 5/6] arm64: mm: Remove arch_apei_flush_tlb_one()

Nothing calls arch_apei_flush_tlb_one() anymore, instead relying on __set_fixmap() to do the invalidation. Remove it. Move the IPI-considered-harmful comment to __set_fixmap(). Signed-off-by: James Morse <james.mo...@arm.com> --- arch/arm64/include/asm/acpi.h | 12 arch/ar

[RFC/RFT PATCH 5/6] arm64: mm: Remove arch_apei_flush_tlb_one()

Nothing calls arch_apei_flush_tlb_one() anymore, instead relying on __set_fixmap() to do the invalidation. Remove it. Move the IPI-considered-harmful comment to __set_fixmap(). Signed-off-by: James Morse --- arch/arm64/include/asm/acpi.h | 12 arch/arm64/mm/mmu.c | 4

[RFC/RFT PATCH 6/6] ACPI / APEI: Remove arch_apei_flush_tlb_one()

Nothing calls arch_apei_flush_tlb_one() anymore, instead relying on __set_pte_vaddr() to do the invalidation when called from clear_fixmap() Remove arch_apei_flush_tlb_one(). Signed-off-by: James Morse <james.mo...@arm.com> --- arch/x86/kernel/acpi/apei.c | 5 - include/acpi/

[RFC/RFT PATCH 6/6] ACPI / APEI: Remove arch_apei_flush_tlb_one()

Nothing calls arch_apei_flush_tlb_one() anymore, instead relying on __set_pte_vaddr() to do the invalidation when called from clear_fixmap() Remove arch_apei_flush_tlb_one(). Signed-off-by: James Morse --- arch/x86/kernel/acpi/apei.c | 5 - include/acpi/apei.h | 1 - 2 files changed

[RFC/RFT PATCH 1/6] arm64: fixmap: Add GHES fixmap entries

GHES is switching to use fixmap for its dynamic mapping of CPER records, to avoid using ioremap_page_range() in IRQ/NMI context. Signed-off-by: James Morse <james.mo...@arm.com> --- arch/arm64/include/asm/fixmap.h | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/inclu

[RFC/RFT PATCH 2/6] x86/mm/fixmap: Add GHES fixmap entries

GHES is switching to use fixmap for its dynamic mapping of CPER records, to avoid using ioremap_page_range() in IRQ/NMI context. Signed-off-by: James Morse <james.mo...@arm.com> --- arch/x86/include/asm/fixmap.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/x86/inclu

[RFC/RFT PATCH 1/6] arm64: fixmap: Add GHES fixmap entries

GHES is switching to use fixmap for its dynamic mapping of CPER records, to avoid using ioremap_page_range() in IRQ/NMI context. Signed-off-by: James Morse --- arch/arm64/include/asm/fixmap.h | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64

[RFC/RFT PATCH 2/6] x86/mm/fixmap: Add GHES fixmap entries

GHES is switching to use fixmap for its dynamic mapping of CPER records, to avoid using ioremap_page_range() in IRQ/NMI context. Signed-off-by: James Morse --- arch/x86/include/asm/fixmap.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include

[RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

. RFC as I've only build-tested this on x86. For arm64 I've tested it on a software model. Any more testing would be welcome. These patches are based on rc7. Thanks, James Morse (6): arm64: fixmap: Add GHES fixmap entries x86/mm/fixmap: Add GHES fixmap entries ACPI / APEI: Replace

[RFC/RFT PATCH 0/6] Switch GHES ioremap_page_range() to use fixmap

. RFC as I've only build-tested this on x86. For arm64 I've tested it on a software model. Any more testing would be welcome. These patches are based on rc7. Thanks, James Morse (6): arm64: fixmap: Add GHES fixmap entries x86/mm/fixmap: Add GHES fixmap entries ACPI / APEI: Replace

Re: [PATCH v7 1/4] arm64: kvm: route synchronous external abort exceptions to EL2

Hi Dongjiu Geng, On 17/10/17 15:14, Dongjiu Geng wrote: > ARMv8.2 adds a new bit HCR_EL2.TEA which controls to > route synchronous external aborts to EL2, and adds a > trap control bit HCR_EL2.TERR which controls to > trap all Non-secure EL1&0 error record accesses to EL2. The bulk of this patch

Re: [PATCH v7 1/4] arm64: kvm: route synchronous external abort exceptions to EL2

Hi Dongjiu Geng, On 17/10/17 15:14, Dongjiu Geng wrote: > ARMv8.2 adds a new bit HCR_EL2.TEA which controls to > route synchronous external aborts to EL2, and adds a > trap control bit HCR_EL2.TERR which controls to > trap all Non-secure EL1&0 error record accesses to EL2. The bulk of this patch

Re: [PATCH v5 2/2] acpi: apei: Add SEI notification type support for ARMv8

ess with an SError? We don't get one for IRQs, but that never needs stating. > Cc: Borislav Petkov <b...@suse.de> > Cc: James Morse <james.mo...@arm.com> > Signed-off-by: Dongjiu Geng <gengdong...@huawei.com> > Tested-by: Tyler Baicar <tbai...@codeaurora.org> >

Re: [PATCH v5 2/2] acpi: apei: Add SEI notification type support for ARMv8

ess with an SError? We don't get one for IRQs, but that never needs stating. > Cc: Borislav Petkov > Cc: James Morse > Signed-off-by: Dongjiu Geng > Tested-by: Tyler Baicar > Tested-by: Dongjiu Geng (It's expected you test your own code) > diff --git a/arch/arm64/mm/

Re: [PATCH v5 2/2] acpi: apei: Add SEI notification type support for ARMv8

Hi Borislav! On 18/10/17 10:25, Borislav Petkov wrote: > On Wed, Oct 18, 2017 at 05:17:27PM +0800, gengdongjiu wrote: >> Thanks Borislav, can I write it as asynchronous exception or >> asynchronous abort? > > WTF?! Yup. > The thing is abbreviated as "SEI" and apparently means "System Error >

Re: [PATCH v5 2/2] acpi: apei: Add SEI notification type support for ARMv8

Hi Borislav! On 18/10/17 10:25, Borislav Petkov wrote: > On Wed, Oct 18, 2017 at 05:17:27PM +0800, gengdongjiu wrote: >> Thanks Borislav, can I write it as asynchronous exception or >> asynchronous abort? > > WTF?! Yup. > The thing is abbreviated as "SEI" and apparently means "System Error >

Re: [PATCH v6 5/7] arm64: kvm: route synchronous external abort exceptions to el2

Hi gengdongjiu, On 14/09/17 12:12, gengdongjiu wrote: > On 2017/9/8 0:31, James Morse wrote: >> KVM already handles external aborts from lower exception levels, no more work >> needs doing for TEA. > If it is firmware first solution, that is SCR_EL3.EA=1, all SError interrupt

Re: [PATCH v6 5/7] arm64: kvm: route synchronous external abort exceptions to el2

Hi gengdongjiu, On 14/09/17 12:12, gengdongjiu wrote: > On 2017/9/8 0:31, James Morse wrote: >> KVM already handles external aborts from lower exception levels, no more work >> needs doing for TEA. > If it is firmware first solution, that is SCR_EL3.EA=1, all SError interrupt

Re: [PATCH 2/3] arm64: vdso: replace gettimeofday.S with arm vgettimeofday.C

Hi Mark, On 11/09/17 17:18, 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. > >

Re: [PATCH 2/3] arm64: vdso: replace gettimeofday.S with arm vgettimeofday.C

Hi Mark, On 11/09/17 17:18, 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. > > apin...@cavium.com writes in the

Re: [PATCH 1/3] arm: vdso: Rewrite gettimeofday to more closely match arm64 variant

Hi Mark, On 11/09/17 17:18, 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. > > Side effects

Re: [PATCH 1/3] arm: vdso: Rewrite gettimeofday to more closely match arm64 variant

Hi Mark, On 11/09/17 17:18, 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. > > Side effects include renaming some

Re: [PATCH v6 6/7] KVM: arm64: allow get exception information from userspace

Hi gengdongjiu, On 27/09/17 12:07, gengdongjiu wrote: > On 2017/9/23 0:51, James Morse wrote: >> If this wasn't a firmware-first notification, then you're right KVM hands the >> guest an asynchronous external abort. This could be considered a bug in KVM. >> (we >

Re: [PATCH v6 6/7] KVM: arm64: allow get exception information from userspace

Hi gengdongjiu, On 27/09/17 12:07, gengdongjiu wrote: > On 2017/9/23 0:51, James Morse wrote: >> If this wasn't a firmware-first notification, then you're right KVM hands the >> guest an asynchronous external abort. This could be considered a bug in KVM. >> (we >

Re: [RFC PATCH v2 19/31] KVM: arm64: Describe AT instruction emulation design

Hi Jintack, On 03/10/17 04:11, Jintack Lim wrote: > This design overview will help to digest the subsequent patches that > implement AT instruction emulation. > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 8d04926..d8728cc 100644 > --- a/arch/arm64/kvm/sys_regs.c >

Re: [RFC PATCH v2 19/31] KVM: arm64: Describe AT instruction emulation design

Hi Jintack, On 03/10/17 04:11, Jintack Lim wrote: > This design overview will help to digest the subsequent patches that > implement AT instruction emulation. > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index 8d04926..d8728cc 100644 > --- a/arch/arm64/kvm/sys_regs.c >

Re: [PATCH v6 6/7] KVM: arm64: allow get exception information from userspace

Hi gengdongjiu, On 21/09/17 08:55, gengdongjiu wrote: > On 2017/9/14 21:00, James Morse wrote: >> user-space can choose whether to use SEA or SEI, it doesn't have to choose >> the >> same notification type that firmware used, which in turn doesn't have to be >&g

Re: [PATCH v6 6/7] KVM: arm64: allow get exception information from userspace

Hi gengdongjiu, On 21/09/17 08:55, gengdongjiu wrote: > On 2017/9/14 21:00, James Morse wrote: >> user-space can choose whether to use SEA or SEI, it doesn't have to choose >> the >> same notification type that firmware used, which in turn doesn't have to be >&g

Re: [PATCH v6 6/7] KVM: arm64: allow get exception information from userspace

Hi gengdongjiu, On 18/09/17 14:36, gengdongjiu wrote: > On 2017/9/14 21:00, James Morse wrote: >> On 13/09/17 08:32, gengdongjiu wrote: >>> On 2017/9/8 0:30, James Morse wrote: >>>> On 28/08/17 11:38, Dongjiu Geng wrote: >>>> For BUS_MCE

Re: [PATCH v6 6/7] KVM: arm64: allow get exception information from userspace

Hi gengdongjiu, On 18/09/17 14:36, gengdongjiu wrote: > On 2017/9/14 21:00, James Morse wrote: >> On 13/09/17 08:32, gengdongjiu wrote: >>> On 2017/9/8 0:30, James Morse wrote: >>>> On 28/08/17 11:38, Dongjiu Geng wrote: >>>> For BUS_MCE

Re: [PATCH] arm64: Unconditionally support ARCH_HAVE_NMI_SAFE_CMPXCHG

GERS need this for? I can't see any cmpxchg use in kernel/trace/trace_events_hist.c Regardless, Acked-by: James Morse <james.mo...@arm.com> Thanks, James > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 0df64a6a56d4..27ce2ab7b080 100644 > --- a/arch/arm64/Kconfig &

Re: [PATCH] arm64: Unconditionally support ARCH_HAVE_NMI_SAFE_CMPXCHG

GERS need this for? I can't see any cmpxchg use in kernel/trace/trace_events_hist.c Regardless, Acked-by: James Morse Thanks, James > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 0df64a6a56d4..27ce2ab7b080 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig

Re: [PATCH v3 1/3] arm64/ras: support sea error recovery

Hi Xie XiuQi, On 11/09/17 15:11, Xie XiuQi wrote: > I first describe the approach of this patchset: > > A memory access error on the execution path usually triggers SEA. > According to the existing process, errors occurred in the kernel, > leading to direct panic, if it occurred the user-space,

Re: [PATCH v3 1/3] arm64/ras: support sea error recovery

Hi Xie XiuQi, On 11/09/17 15:11, Xie XiuQi wrote: > I first describe the approach of this patchset: > > A memory access error on the execution path usually triggers SEA. > According to the existing process, errors occurred in the kernel, > leading to direct panic, if it occurred the user-space,

Re: [PATCH v6 6/7] KVM: arm64: allow get exception information from userspace

Hi gengdongjiu, (re-ordered hunks) On 13/09/17 08:32, gengdongjiu wrote: > On 2017/9/8 0:30, James Morse wrote: >> On 28/08/17 11:38, Dongjiu Geng wrote: >> For BUS_MCEERR_A* from memory_failure() we can't know if they are caused by >> an access or not. Actually it looks l

Re: [PATCH v6 6/7] KVM: arm64: allow get exception information from userspace

Hi gengdongjiu, (re-ordered hunks) On 13/09/17 08:32, gengdongjiu wrote: > On 2017/9/8 0:30, James Morse wrote: >> On 28/08/17 11:38, Dongjiu Geng wrote: >> For BUS_MCEERR_A* from memory_failure() we can't know if they are caused by >> an access or not. Actually it looks l

Re: [PATCH v6 5/7] arm64: kvm: route synchronous external abort exceptions to el2

Hi gengdongjiu, On 14/09/17 12:12, gengdongjiu wrote: > On 2017/9/8 0:31, James Morse wrote: >> KVM already handles external aborts from lower exception levels, no more work >> needs doing for TEA. > If it is firmware first solution, that is SCR_EL3.EA=1, all SError interrupt

Re: [PATCH v6 5/7] arm64: kvm: route synchronous external abort exceptions to el2

Hi gengdongjiu, On 14/09/17 12:12, gengdongjiu wrote: > On 2017/9/8 0:31, James Morse wrote: >> KVM already handles external aborts from lower exception levels, no more work >> needs doing for TEA. > If it is firmware first solution, that is SCR_EL3.EA=1, all SError interrupt

Re: [PATCH v6 3/7] acpi: apei: remove the unused code

Hi gengdongjiu, On 11/09/17 13:04, gengdongjiu wrote: > On 2017/9/9 2:17, James Morse wrote: >> On 04/09/17 12:43, gengdongjiu wrote: >>> On 2017/9/1 1:50, James Morse wrote: >>>> On 28/08/17 11:38, Dongjiu Geng wrote: >>>> If you aren't handling th

Re: [PATCH v6 3/7] acpi: apei: remove the unused code

Hi gengdongjiu, On 11/09/17 13:04, gengdongjiu wrote: > On 2017/9/9 2:17, James Morse wrote: >> On 04/09/17 12:43, gengdongjiu wrote: >>> On 2017/9/1 1:50, James Morse wrote: >>>> On 28/08/17 11:38, Dongjiu Geng wrote: >>>> If you aren't handling th

Re: [PATCH v2] arm64: fix unwind_frame() for filtered out fn for function graph tracing

Hi Pratyush, On 01/09/17 06:48, Pratyush Anand wrote: > do_task_stat() calls get_wchan(), which further does unbind_frame(). > unbind_frame() restores frame->pc to original value in case function > graph tracer has modified a return address (LR) in a stack frame to hook > a function return.

Re: [PATCH v2] arm64: fix unwind_frame() for filtered out fn for function graph tracing

Hi Pratyush, On 01/09/17 06:48, Pratyush Anand wrote: > do_task_stat() calls get_wchan(), which further does unbind_frame(). > unbind_frame() restores frame->pc to original value in case function > graph tracer has modified a return address (LR) in a stack frame to hook > a function return.

Re: [PATCH v6 3/7] acpi: apei: remove the unused code

Hi gengdongjiu, On 04/09/17 12:43, gengdongjiu wrote: > On 2017/9/1 1:50, James Morse wrote: >> On 28/08/17 11:38, Dongjiu Geng wrote: >>> In current code logic, the two functions ghes_sea_add() and >>> ghes_sea_remove() are only called when CONFIG_A

Re: [PATCH v6 3/7] acpi: apei: remove the unused code

Hi gengdongjiu, On 04/09/17 12:43, gengdongjiu wrote: > On 2017/9/1 1:50, James Morse wrote: >> On 28/08/17 11:38, Dongjiu Geng wrote: >>> In current code logic, the two functions ghes_sea_add() and >>> ghes_sea_remove() are only called when CONFIG_A

Re: [PATCH v3 1/3] arm64/ras: support sea error recovery

Hi Xie XiuQi, (Sorry a few versions of this went past before I caught up with it) On 07/09/17 08:45, Xie XiuQi wrote: > With ARM v8.2 RAS Extension, SEA are usually triggered when memory errors > are consumed. In some cases, if the error address is in a clean page or a > read-only page, there is

Re: [PATCH v3 1/3] arm64/ras: support sea error recovery

Hi Xie XiuQi, (Sorry a few versions of this went past before I caught up with it) On 07/09/17 08:45, Xie XiuQi wrote: > With ARM v8.2 RAS Extension, SEA are usually triggered when memory errors > are consumed. In some cases, if the error address is in a clean page or a > read-only page, there is

Re: [PATCH v6 0/7] Add RAS virtualization support for SEA/SEI notification type in KVM

Hi gengdongjiu, (I've re-ordered some of the hunks here:) On 04/09/17 12:10, gengdongjiu wrote: > On 2017/9/1 1:43, James Morse wrote: >> On 28/08/17 11:38, Dongjiu Geng wrote: >>> Not call memory_failure() to handle it. Because the error address recorded >>> by AP

Re: [PATCH v6 0/7] Add RAS virtualization support for SEA/SEI notification type in KVM

Hi gengdongjiu, (I've re-ordered some of the hunks here:) On 04/09/17 12:10, gengdongjiu wrote: > On 2017/9/1 1:43, James Morse wrote: >> On 28/08/17 11:38, Dongjiu Geng wrote: >>> Not call memory_failure() to handle it. Because the error address recorded >>> by AP

Re: [PATCH v6 4/7] arm64: kvm: support user space to query RAS extension feature

Hi gengdongjiu, On 05/09/17 08:18, gengdongjiu wrote: > On 2017/9/1 2:04, James Morse wrote: >> On 28/08/17 11:38, Dongjiu Geng wrote: >>> Userspace will want to check if the CPU has the RAS >>> extension. >> >> ... but user-space wants to know if it can

Re: [PATCH v6 4/7] arm64: kvm: support user space to query RAS extension feature

Hi gengdongjiu, On 05/09/17 08:18, gengdongjiu wrote: > On 2017/9/1 2:04, James Morse wrote: >> On 28/08/17 11:38, Dongjiu Geng wrote: >>> Userspace will want to check if the CPU has the RAS >>> extension. >> >> ... but user-space wants to know if it can

Re: [PATCH v6 5/7] arm64: kvm: route synchronous external abort exceptions to el2

Hi Dongjiu Geng, On 28/08/17 11:38, Dongjiu Geng wrote: > ARMv8.2 adds a new bit HCR_EL2.TEA which controls to > route synchronous external aborts to EL2, and adds a > trap control bit HCR_EL2.TERR which controls to > trap all Non-secure EL1&0 error record accesses to EL2. > > This patch enables

Re: [PATCH v6 5/7] arm64: kvm: route synchronous external abort exceptions to el2

Hi Dongjiu Geng, On 28/08/17 11:38, Dongjiu Geng wrote: > ARMv8.2 adds a new bit HCR_EL2.TEA which controls to > route synchronous external aborts to EL2, and adds a > trap control bit HCR_EL2.TERR which controls to > trap all Non-secure EL1&0 error record accesses to EL2. > > This patch enables

Re: [PATCH v6 6/7] KVM: arm64: allow get exception information from userspace

Hi Dongjiu Geng, On 28/08/17 11:38, Dongjiu Geng wrote: > when userspace gets SIGBUS signal, it does not know whether > this is a synchronous external abort or SError, Why would Qemu/kvmtool need to know if the original notification (if there was one) was synchronous or asynchronous? This is

Re: [PATCH v6 6/7] KVM: arm64: allow get exception information from userspace

Hi Dongjiu Geng, On 28/08/17 11:38, Dongjiu Geng wrote: > when userspace gets SIGBUS signal, it does not know whether > this is a synchronous external abort or SError, Why would Qemu/kvmtool need to know if the original notification (if there was one) was synchronous or asynchronous? This is

Re: [PATCH] arm64: KVM: VHE: reset PSTATE.UAO when switch to host

Hi Dongjiu Geng, On 07/09/17 06:54, Dongjiu Geng wrote: > In VHE mode, host kernel runs in the EL2 and can enable > 'User Access Override' when fs==KERNEL_DS so that it can > access kernel memory. However, PSTATE.UAO is set to 0 on > an exception taken from EL1 to EL2. Thus when VHE is used > and

Re: [PATCH] arm64: KVM: VHE: reset PSTATE.UAO when switch to host

Hi Dongjiu Geng, On 07/09/17 06:54, Dongjiu Geng wrote: > In VHE mode, host kernel runs in the EL2 and can enable > 'User Access Override' when fs==KERNEL_DS so that it can > access kernel memory. However, PSTATE.UAO is set to 0 on > an exception taken from EL1 to EL2. Thus when VHE is used > and

Re: [PATCH v6 4/7] arm64: kvm: support user space to query RAS extension feature

Hi Dongjiu Geng, On 28/08/17 11:38, Dongjiu Geng wrote: > In ARMV8.2 RAS extension, a virtual SError exception syndrome > register(VSESR_EL2) is added. This value may be specified from > userspace. I agree that the CPU support for injecting SErrors with a specified ESR should be exposed to

Re: [PATCH v6 4/7] arm64: kvm: support user space to query RAS extension feature

Hi Dongjiu Geng, On 28/08/17 11:38, Dongjiu Geng wrote: > In ARMV8.2 RAS extension, a virtual SError exception syndrome > register(VSESR_EL2) is added. This value may be specified from > userspace. I agree that the CPU support for injecting SErrors with a specified ESR should be exposed to

Re: [PATCH v6 3/7] acpi: apei: remove the unused code

Hi Dongjiu Geng, On 28/08/17 11:38, Dongjiu Geng wrote: > In current code logic, the two functions ghes_sea_add() and > ghes_sea_remove() are only called when CONFIG_ACPI_APEI_SEA > is defined. If not, it will return errors in the ghes_probe() > and not contiue. Hence, remove the unnecessary

Re: [PATCH v6 3/7] acpi: apei: remove the unused code

Hi Dongjiu Geng, On 28/08/17 11:38, Dongjiu Geng wrote: > In current code logic, the two functions ghes_sea_add() and > ghes_sea_remove() are only called when CONFIG_ACPI_APEI_SEA > is defined. If not, it will return errors in the ghes_probe() > and not contiue. Hence, remove the unnecessary

Re: [PATCH v6 1/7] arm64: cpufeature: Detect CPU RAS Extentions

rt may require additional firmware support. > > Signed-off-by: Xie XiuQi <xiexi...@huawei.com> > [Rebased, added esb and config option, reworded commit message] > Signed-off-by: James Morse <james.mo...@arm.com> Nit: when re-posting patches from the list you need to add yo

Re: [PATCH v6 1/7] arm64: cpufeature: Detect CPU RAS Extentions

al firmware support. > > Signed-off-by: Xie XiuQi > [Rebased, added esb and config option, reworded commit message] > Signed-off-by: James Morse Nit: when re-posting patches from the list you need to add your signed-off-by. See Documentation/process/submitting-patches.rst 'Developer'

Re: [PATCH v6 0/7] Add RAS virtualization support for SEA/SEI notification type in KVM

Hi Dongjiu Geng, On 28/08/17 11:38, Dongjiu Geng wrote: > In the firmware-first RAS solution, corrupt data is detected in a > memory location when guest OS application software executing at EL0 > or guest OS kernel El1 software are reading from the memory. The > memory node records errors in an

Re: [PATCH v6 0/7] Add RAS virtualization support for SEA/SEI notification type in KVM

Hi Dongjiu Geng, On 28/08/17 11:38, Dongjiu Geng wrote: > In the firmware-first RAS solution, corrupt data is detected in a > memory location when guest OS application software executing at EL0 > or guest OS kernel El1 software are reading from the memory. The > memory node records errors in an

Re: [PATCH] arm64: fix unwind_frame() for filtered out fn via set_graph_notrace

Hi Pratyush, (Nit: get_maintainer.pl will give you the list of people to CC, you're reliant on the maintainers being eagle-eyed to spot this!) On 28/08/17 13:53, Pratyush Anand wrote: > Testcase: > cd /sys/kernel/debug/tracing/ > echo schedule > set_graph_notrace > echo 1 > options/display-graph

Re: [PATCH] arm64: fix unwind_frame() for filtered out fn via set_graph_notrace

Hi Pratyush, (Nit: get_maintainer.pl will give you the list of people to CC, you're reliant on the maintainers being eagle-eyed to spot this!) On 28/08/17 13:53, Pratyush Anand wrote: > Testcase: > cd /sys/kernel/debug/tracing/ > echo schedule > set_graph_notrace > echo 1 > options/display-graph

Re: [PATCHv2] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

be called twice in panic path, but obviously > + * we execute this only once. > + */ > + if (cpus_stopped) > + return; > + > + cpus_stopped = 1; > + This cpus_stopped=1 can't happen on multiple CPUs at the same time as any second call is guaranteed t

Re: [PATCHv2] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

be called twice in panic path, but obviously > + * we execute this only once. > + */ > + if (cpus_stopped) > + return; > + > + cpus_stopped = 1; > + This cpus_stopped=1 can't happen on multiple CPUs at the same time as any second call is guaranteed to be on the same CPU, both are behind panic()s 'atomic_cmpxchg()'. Other than my '/proc/vmcore is not available' question above, this looks fine to me: Reviewed-by: James Morse Tested-by: James Morse Thanks! James

Re: [PATCH] KVM: arm64: add esr_el2 and far_el2 to sysreg

Hi gengdongjiu, On 07/08/17 18:43, gengdongjiu wrote: > Another question, For the SEI, I want to also use SIGBUS both for the KVM > user and non-kvm user, > if SEA and SEI Error all use the SIGBUS to notify user space(Qemu), User-space shouldn't necessarily be notified about Synchronous

Re: [PATCH] KVM: arm64: add esr_el2 and far_el2 to sysreg

Hi gengdongjiu, On 07/08/17 18:43, gengdongjiu wrote: > Another question, For the SEI, I want to also use SIGBUS both for the KVM > user and non-kvm user, > if SEA and SEI Error all use the SIGBUS to notify user space(Qemu), User-space shouldn't necessarily be notified about Synchronous

Re: [PATCH] KVM: arm64: add esr_el2 and far_el2 to sysreg

Hi gengdongjiu, On 07/08/17 17:23, gengdongjiu wrote: > As James's suggestion, I move injection SEA Error logic to the user > space(Qemu), Qemu sets the related guest OS esr/elr/pstate/spsr (because for firmware-first its the CPER records that matter, and only QEMU knows where it reserved the

Re: [PATCH] KVM: arm64: add esr_el2 and far_el2 to sysreg

Hi gengdongjiu, On 07/08/17 17:23, gengdongjiu wrote: > As James's suggestion, I move injection SEA Error logic to the user > space(Qemu), Qemu sets the related guest OS esr/elr/pstate/spsr (because for firmware-first its the CPER records that matter, and only QEMU knows where it reserved the

Re: [PATCH] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

Hi Hoeun, On 04/08/17 08:02, Hoeun Ryu wrote: > Commit 0ee5941 : (x86/panic: replace smp_send_stop() with kdump friendly > version in panic path) introduced crash_smp_send_stop() which is a weak > function and can be overriden by architecture codes to fix the side effect > caused by commit

Re: [PATCH] arm64:kexec: have own crash_smp_send_stop() for crash dump for nonpanic cores

Hi Hoeun, On 04/08/17 08:02, Hoeun Ryu wrote: > Commit 0ee5941 : (x86/panic: replace smp_send_stop() with kdump friendly > version in panic path) introduced crash_smp_send_stop() which is a weak > function and can be overriden by architecture codes to fix the side effect > caused by commit

Re: [PATCH v3 0/5] ARM64: disable irq between breakpoint and step exception

Hi Pratyush, On 02/08/17 19:46, Pratyush Anand wrote: > In my understanding problems are: > (1) Single stepping of unwanted instruction (ie. instruction next to > enable_dbg > from el1_irq) > (2) We do not have memory at the end of el1_irq, so that we can set watchpoint > exception generating

Re: [PATCH v3 0/5] ARM64: disable irq between breakpoint and step exception

Hi Pratyush, On 02/08/17 19:46, Pratyush Anand wrote: > In my understanding problems are: > (1) Single stepping of unwanted instruction (ie. instruction next to > enable_dbg > from el1_irq) > (2) We do not have memory at the end of el1_irq, so that we can set watchpoint > exception generating

Re: [PATCH v3 0/5] ARM64: disable irq between breakpoint and step exception

Hi Pratyush, On 01/08/17 05:18, Pratyush Anand wrote: > On Monday 31 July 2017 10:45 PM, James Morse wrote: >> On 31/07/17 11:40, Pratyush Anand wrote: >>> samples/hw_breakpoint/data_breakpoint.c passes with x86_64 but fails with >>> ARM64. Even though it has been NAKe

Re: [PATCH v3 0/5] ARM64: disable irq between breakpoint and step exception

Hi Pratyush, On 01/08/17 05:18, Pratyush Anand wrote: > On Monday 31 July 2017 10:45 PM, James Morse wrote: >> On 31/07/17 11:40, Pratyush Anand wrote: >>> samples/hw_breakpoint/data_breakpoint.c passes with x86_64 but fails with >>> ARM64. Even though it has been NAKe

Re: [PATCH v3 0/5] ARM64: disable irq between breakpoint and step exception

Hi Pratyush, On 31/07/17 11:40, Pratyush Anand wrote: > samples/hw_breakpoint/data_breakpoint.c passes with x86_64 but fails with > ARM64. Even though it has been NAKed previously on upstream [1, 2], I have > tried to come up with patches which can resolve it for ARM64 as well. > > I noticed

Re: [PATCH v3 0/5] ARM64: disable irq between breakpoint and step exception

Hi Pratyush, On 31/07/17 11:40, Pratyush Anand wrote: > samples/hw_breakpoint/data_breakpoint.c passes with x86_64 but fails with > ARM64. Even though it has been NAKed previously on upstream [1, 2], I have > tried to come up with patches which can resolve it for ARM64 as well. > > I noticed

Re: [PATCH] acpi: apei: clear error status before acknowledging the error

Hi Tyler, On 31/07/17 17:15, Baicar, Tyler wrote: > On 7/29/2017 12:53 AM, Borislav Petkov wrote: >> On Fri, Jul 28, 2017 at 04:25:03PM -0600, Tyler Baicar wrote: >>> Currently we acknowledge errors before clearing the error status. >>> This could cause a new error to be populated by firmware

Re: [PATCH] acpi: apei: clear error status before acknowledging the error

Hi Tyler, On 31/07/17 17:15, Baicar, Tyler wrote: > On 7/29/2017 12:53 AM, Borislav Petkov wrote: >> On Fri, Jul 28, 2017 at 04:25:03PM -0600, Tyler Baicar wrote: >>> Currently we acknowledge errors before clearing the error status. >>> This could cause a new error to be populated by firmware

Re: [kernel-hardening] Re: [RFC PATCH 6/6] arm64: add VMAP_STACK and detect out-of-bounds SP

Hi Ard, On 20/07/17 06:35, Ard Biesheuvel wrote: > On 20 July 2017 at 00:32, Laura Abbott wrote: >> I didn't notice any performance impact but I also wasn't trying that >> hard. I did try this with a different configuration and ran into >> stackspace errors almost

Re: [kernel-hardening] Re: [RFC PATCH 6/6] arm64: add VMAP_STACK and detect out-of-bounds SP

Hi Ard, On 20/07/17 06:35, Ard Biesheuvel wrote: > On 20 July 2017 at 00:32, Laura Abbott wrote: >> I didn't notice any performance impact but I also wasn't trying that >> hard. I did try this with a different configuration and ran into >> stackspace errors almost immediately: >> >> [ 0.358026]

Re: [PATCH] ptrace: Add compat PTRACE_{G,S}ETSIGMASK handlers

Hi Michael, On 17/07/17 11:17, Michael Ellerman wrote: > James Morse <james.mo...@arm.com> writes: >> compat_ptrace_request() lacks handlers for PTRACE_{G,S}ETSIGMASK, >> instead using those in ptrace_request(). The compat variant should >> read a compat_sigs

Re: [PATCH] ptrace: Add compat PTRACE_{G,S}ETSIGMASK handlers

Hi Michael, On 17/07/17 11:17, Michael Ellerman wrote: > James Morse writes: >> compat_ptrace_request() lacks handlers for PTRACE_{G,S}ETSIGMASK, >> instead using those in ptrace_request(). The compat variant should >> read a compat_sigset_t from userspace instead

Re: [RFC PATCH 2/6] arm64: avoid open-coding THREAD_SIZE{,_ORDER}

Hi Mark, On 12/07/17 23:32, Mark Rutland wrote: > Currently we define THREAD_SIZE_ORDER dependent on which arm64-specific > page size kconfig symbol was selected. This is unfortunate, as it hides > the relationship between THREAD_SIZE_ORDER and THREAD_SIZE, and makes it > painful more painful

Re: [RFC PATCH 2/6] arm64: avoid open-coding THREAD_SIZE{,_ORDER}

Hi Mark, On 12/07/17 23:32, Mark Rutland wrote: > Currently we define THREAD_SIZE_ORDER dependent on which arm64-specific > page size kconfig symbol was selected. This is unfortunate, as it hides > the relationship between THREAD_SIZE_ORDER and THREAD_SIZE, and makes it > painful more painful

Re: [PATCH 1/2] arm64: mm: abort uaccess retries upon fatal signal

at code to make forward > progress towards delivering the fatal signal. VM_FAULT_RETRY's 'I released your locks' behaviour is pretty nasty, but this looks right. FWIW: Reviewed-by: James Morse <james.mo...@arm.com> I also gave this a spin through LTP on Juno, based on v4.12-defconfig: Te

Re: [PATCH 1/2] arm64: mm: abort uaccess retries upon fatal signal

at code to make forward > progress towards delivering the fatal signal. VM_FAULT_RETRY's 'I released your locks' behaviour is pretty nasty, but this looks right. FWIW: Reviewed-by: James Morse I also gave this a spin through LTP on Juno, based on v4.12-defconfig: Tested-by: James Morse Thanks, James

Re: [PATCH v4 3/3] arm64: kvm: inject SError with user space specified syndrome

Hi gengdongjiu, On 05/07/17 09:14, gengdongjiu wrote: > On 2017/7/4 18:14, James Morse wrote: >> Can you give us a specific example of an error you are trying to handle? > For example: > guest OS user space accesses device type memory, but happen SError. because > the > S

Re: [PATCH v4 3/3] arm64: kvm: inject SError with user space specified syndrome

Hi gengdongjiu, On 05/07/17 09:14, gengdongjiu wrote: > On 2017/7/4 18:14, James Morse wrote: >> Can you give us a specific example of an error you are trying to handle? > For example: > guest OS user space accesses device type memory, but happen SError. because > the > S

Re: [PATCH v4 3/3] arm64: kvm: inject SError with user space specified syndrome

Hi gengdongjiu, Can you give us a specific example of an error you are trying to handle? How would a non-KVM user space process handle the error? KVM-users should be regular user space processes, we should not have a KVM-way and everyone-else-way of handling errors. On 04/07/17 05:46,

Re: [PATCH v4 3/3] arm64: kvm: inject SError with user space specified syndrome

Hi gengdongjiu, Can you give us a specific example of an error you are trying to handle? How would a non-KVM user space process handle the error? KVM-users should be regular user space processes, we should not have a KVM-way and everyone-else-way of handling errors. On 04/07/17 05:46,

[PATCH] ptrace: Add compat PTRACE_{G,S}ETSIGMASK handlers

significant. Instead of duplicating ptrace_request()s code as a special case in the arch code, handle it here. CC: Yury Norov <yno...@caviumnetworks.com> CC: Andrey Vagin <ava...@openvz.org> Reported-by: Zhou Chengming <zhouchengmi...@huawei.com> Signed-off-by: James Morse <james

[PATCH] ptrace: Add compat PTRACE_{G,S}ETSIGMASK handlers

significant. Instead of duplicating ptrace_request()s code as a special case in the arch code, handle it here. CC: Yury Norov CC: Andrey Vagin Reported-by: Zhou Chengming Signed-off-by: James Morse Fixes: 29000caecbe87 ("ptrace: add ability to get/set signal-blocked mask") --- LTP test

Re: [PATCH v5] trace: ras: add ARM processor error information trace event

Hi guys, (CC: Punit) On 26/06/17 15:06, Borislav Petkov wrote: > On Sat, Jun 24, 2017 at 11:38:23AM +0800, Xie XiuQi wrote: >> Add a new trace event for ARM processor error information, so that >> the user will know what error occurred. With this information the >> user may take appropriate

Re: [PATCH v5] trace: ras: add ARM processor error information trace event

Hi guys, (CC: Punit) On 26/06/17 15:06, Borislav Petkov wrote: > On Sat, Jun 24, 2017 at 11:38:23AM +0800, Xie XiuQi wrote: >> Add a new trace event for ARM processor error information, so that >> the user will know what error occurred. With this information the >> user may take appropriate

Re: [PATCH 18/20] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

Hi Yury, Zhou, On 23/06/17 23:28, Yury Norov wrote: > On Fri, Jun 23, 2017 at 06:03:37PM +0100, James Morse wrote: >> Hi Yury, >> >> On 04/06/17 13:00, Yury Norov wrote: >>> ILP32 has context-related structures different from both aarch32 and >>> aarch64

Re: [PATCH 18/20] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

Hi Yury, Zhou, On 23/06/17 23:28, Yury Norov wrote: > On Fri, Jun 23, 2017 at 06:03:37PM +0100, James Morse wrote: >> Hi Yury, >> >> On 04/06/17 13:00, Yury Norov wrote: >>> ILP32 has context-related structures different from both aarch32 and >>> aarch64

<    3   4   5   6   7   8   9   10   11   >