Re: [PATCH v9 3/7] acpi: apei: Add SEI notification type support for ARMv8

Hi gengdongjiu, liu jun On 05/02/18 11:24, gengdongjiu wrote: > James Morse wrote: >> I'd like to pick these patches onto the end of that series, but first I want >> to >> know what NOTIFY_SEI means for any OS. The ACPI spec doesn't say, and >> because its asynchronou

Re: [PATCH v9 3/7] acpi: apei: Add SEI notification type support for ARMv8

Hi gengdongjiu, liu jun On 05/02/18 11:24, gengdongjiu wrote: > James Morse wrote: >> I'd like to pick these patches onto the end of that series, but first I want >> to >> know what NOTIFY_SEI means for any OS. The ACPI spec doesn't say, and >> because its asynchronou

Re: [PATCH v9 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl

Hi gengdongjiu, On 05/02/18 06:19, gengdongjiu wrote: > On 2018/1/31 3:21, James Morse wrote: >> On 24/01/18 20:06, gengdongjiu wrote: >>>> On 06/01/18 16:02, Dongjiu Geng wrote: >>>>> The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the &g

Re: [PATCH v9 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl

Hi gengdongjiu, On 05/02/18 06:19, gengdongjiu wrote: > On 2018/1/31 3:21, James Morse wrote: >> On 24/01/18 20:06, gengdongjiu wrote: >>>> On 06/01/18 16:02, Dongjiu Geng wrote: >>>>> The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the &g

Re: [PATCH] arm64: acpi,efi: fix alignment fault in accessing ACPI tables at kdump

Hi Akashi, Ard, On 02/02/18 04:35, AKASHI Takahiro wrote: > On Thu, Feb 01, 2018 at 05:34:26PM +, Ard Biesheuvel wrote: >> On 1 February 2018 at 09:04, AKASHI Takahiro >> wrote: >>> * Initial ACPI tables are normally stored in system ram and marked as >>> "ACPI

Re: [PATCH] arm64: acpi,efi: fix alignment fault in accessing ACPI tables at kdump

Hi Akashi, Ard, On 02/02/18 04:35, AKASHI Takahiro wrote: > On Thu, Feb 01, 2018 at 05:34:26PM +, Ard Biesheuvel wrote: >> On 1 February 2018 at 09:04, AKASHI Takahiro >> wrote: >>> * Initial ACPI tables are normally stored in system ram and marked as >>> "ACPI Reclaim memory" by the

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

Hi Xie XiuQi, On 30/01/18 19:19, James Morse wrote: > On 26/01/18 12:31, Xie XiuQi wrote: >> With ARM v8.2 RAS Extension, SEA are usually triggered when memory errors >> are consumed. According to the existing process, errors occurred in the >> kernel, leading to direct

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

Hi Xie XiuQi, On 30/01/18 19:19, James Morse wrote: > On 26/01/18 12:31, Xie XiuQi wrote: >> With ARM v8.2 RAS Extension, SEA are usually triggered when memory errors >> are consumed. According to the existing process, errors occurred in the >> kernel, leading to direct

Re: [PATCH v7 05/11] arm64: kexec_file: create purgatory

Hi Akashi, On 04/12/17 02:57, AKASHI Takahiro wrote: > This is a basic purgatory, or a kind of glue code between the two kernels, > for arm64. > > Since purgatory is assumed to be relocatable (not executable) object by > kexec generic code, arch_kexec_apply_relocations_add() is required in >

Re: [PATCH v7 05/11] arm64: kexec_file: create purgatory

Hi Akashi, On 04/12/17 02:57, AKASHI Takahiro wrote: > This is a basic purgatory, or a kind of glue code between the two kernels, > for arm64. > > Since purgatory is assumed to be relocatable (not executable) object by > kexec generic code, arch_kexec_apply_relocations_add() is required in >

Re: [PATCH v7 00/11] arm64: kexec: add kexec_file_load() support

Hi Akashi, I'm still getting my head round how all this works, so please forgive what may be stupid questions! On 04/12/17 02:57, AKASHI Takahiro wrote: > This is the seventh round of implementing kexec_file_load() support > on arm64.[1] > Most of the code is based on kexec-tools (along with

Re: [PATCH v7 00/11] arm64: kexec: add kexec_file_load() support

Hi Akashi, I'm still getting my head round how all this works, so please forgive what may be stupid questions! On 04/12/17 02:57, AKASHI Takahiro wrote: > This is the seventh round of implementing kexec_file_load() support > on arm64.[1] > Most of the code is based on kexec-tools (along with

Re: [PATCH v7 03/11] kexec_file: factor out crashdump elf header function from x86

Hi Akashi, On 04/12/17 02:57, AKASHI Takahiro wrote: > prepare_elf_headers() can also be useful for other architectures, > including arm64. What does arm64 need this for? This is generating ELF headers for something, but I can't work out what. (I'll keep reading,...) The x86 decompressor? arm64

Re: [PATCH v7 03/11] kexec_file: factor out crashdump elf header function from x86

Hi Akashi, On 04/12/17 02:57, AKASHI Takahiro wrote: > prepare_elf_headers() can also be useful for other architectures, > including arm64. What does arm64 need this for? This is generating ELF headers for something, but I can't work out what. (I'll keep reading,...) The x86 decompressor? arm64

Re: [PATCH v9 3/7] acpi: apei: Add SEI notification type support for ARMv8

Hi gengdongjiu, On 23/01/18 09:23, gengdongjiu wrote: > On 2018/1/23 3:39, James Morse wrote: >> gengdongjiu wrote: >>> This error source parsing and handling method >>> is similar with the SEA. >> >> There are problems with doing this: >> >> Oc

Re: [PATCH v9 3/7] acpi: apei: Add SEI notification type support for ARMv8

Hi gengdongjiu, On 23/01/18 09:23, gengdongjiu wrote: > On 2018/1/23 3:39, James Morse wrote: >> gengdongjiu wrote: >>> This error source parsing and handling method >>> is similar with the SEA. >> >> There are problems with doing this: >> >> Oc

Re: [PATCH v9 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl

Hi gengdongjiu, On 24/01/18 20:06, gengdongjiu wrote: >> On 06/01/18 16:02, Dongjiu Geng wrote: >>> The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the >>> guest and user space needs a way to tell KVM this value. So we add a >>> new ioctl. Before user space specifies the

Re: [PATCH v9 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl

Hi gengdongjiu, On 24/01/18 20:06, gengdongjiu wrote: >> On 06/01/18 16:02, Dongjiu Geng wrote: >>> The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the >>> guest and user space needs a way to tell KVM this value. So we add a >>> new ioctl. Before user space specifies the

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

Hi Xie XiuQi, On 26/01/18 12:31, Xie XiuQi wrote: > With ARM v8.2 RAS Extension, SEA are usually triggered when memory errors > are consumed. According to the existing process, errors occurred in the > kernel, leading to direct panic, if it occurred the user-space, we should > just kill process.

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

Hi Xie XiuQi, On 26/01/18 12:31, Xie XiuQi wrote: > With ARM v8.2 RAS Extension, SEA are usually triggered when memory errors > are consumed. According to the existing process, errors occurred in the > kernel, leading to direct panic, if it occurred the user-space, we should > just kill process.

Re: [PATCH v9 6/7] arm64: kvm: Set Virtual SError Exception Syndrome for guest

ng...@huawei.com> > [Set an impdef ESR for Virtual-SError] > Signed-off-by: James Morse <james.mo...@arm.com> I didn't sign-off this patch. If you pick some bits from another version and want to credit someone else you can 'CC:' them or just mention it in the commit-message. > dif

Re: [PATCH v9 6/7] arm64: kvm: Set Virtual SError Exception Syndrome for guest

sion of this patch has been queued by Catalin. Now that the cpufeature bits are queued, I think this can be split up into two separate series for v4.16-rc1, one to tackle NOTIFY_SEI and the associated plumbing. The second for the KVM 'make SError pending' API. > Signed-off-by: Dongjiu Geng > [Set an im

Re: [PATCH v9 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl

Hi Dongjiu Geng, On 06/01/18 16:02, Dongjiu Geng wrote: > The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the > guest and user space needs a way to tell KVM this value. So we add a > new ioctl. Before user space specifies the Exception Syndrome Register > ESR(ESR), it firstly

Re: [PATCH v9 5/7] arm64: kvm: Introduce KVM_ARM_SET_SERROR_ESR ioctl

Hi Dongjiu Geng, On 06/01/18 16:02, Dongjiu Geng wrote: > The ARM64 RAS SError Interrupt(SEI) syndrome value is specific to the > guest and user space needs a way to tell KVM this value. So we add a > new ioctl. Before user space specifies the Exception Syndrome Register > ESR(ESR), it firstly

Re: [PATCH v9 3/7] acpi: apei: Add SEI notification type support for ARMv8

SEI as a GHES notification mechanism... ", its up to the arch code to spot a v8.2 RAS Error based on the cpu caps. > This error source parsing and handling method > is similar with the SEA. There are problems with doing this: Oct. 18, 2017, 10:26 a.m. James Morse wrote: | How do SEA and

Re: [PATCH v9 3/7] acpi: apei: Add SEI notification type support for ARMv8

SEI as a GHES notification mechanism... ", its up to the arch code to spot a v8.2 RAS Error based on the cpu caps. > This error source parsing and handling method > is similar with the SEA. There are problems with doing this: Oct. 18, 2017, 10:26 a.m. James Morse wrote: | How do SEA and

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi gengdongjiu, On 16/12/17 03:44, gengdongjiu wrote: > On 2017/12/16 2:52, James Morse wrote: >>> signal, it will record the CPER and trigger a IRQ to notify guest, as shown >>> below: >>> >>> SIGBUS_MCEERR_AR trigger Synchronous External Abort

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi gengdongjiu, On 16/12/17 03:44, gengdongjiu wrote: > On 2017/12/16 2:52, James Morse wrote: >>> signal, it will record the CPER and trigger a IRQ to notify guest, as shown >>> below: >>> >>> SIGBUS_MCEERR_AR trigger Synchronous External Abort

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi gengdongjiu, On 21/01/18 02:45, gengdongjiu wrote: > For the ESR_ELx_AET_UER, this exception is precise, closing the VM may > be better[1]. > But if you think panic is better until we support kernel-first, it is > also OK to me. I'm not convinced SError while a guest was running means only

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi gengdongjiu, On 21/01/18 02:45, gengdongjiu wrote: > For the ESR_ELx_AET_UER, this exception is precise, closing the VM may > be better[1]. > But if you think panic is better until we support kernel-first, it is > also OK to me. I'm not convinced SError while a guest was running means only

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

Hi Dave, Thanks for going through all these, On 15/01/18 16:30, Dave Martin wrote: > On Thu, Jan 11, 2018 at 06:59:36PM -0600, Eric W. Biederman wrote: >> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c >> index 9b7f89df49db..abe200587334 100644 >> --- a/arch/arm64/mm/fault.c >> +++

Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

Hi Dave, Thanks for going through all these, On 15/01/18 16:30, Dave Martin wrote: > On Thu, Jan 11, 2018 at 06:59:36PM -0600, Eric W. Biederman wrote: >> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c >> index 9b7f89df49db..abe200587334 100644 >> --- a/arch/arm64/mm/fault.c >> +++

Re: [PATCH -next] firmware: arm_sdei: Fix return value check in sdei_present_dt()

Hi Wei, On 15/01/18 10:41, Wei Yongjun wrote: > In case of error, the function of_platform_device_create() returns > NULL pointer not ERR_PTR(). The IS_ERR() test in the return value > check should be replaced with NULL test. Bother, so it does! Thanks for catching this. Acked-by: Ja

Re: [PATCH -next] firmware: arm_sdei: Fix return value check in sdei_present_dt()

Hi Wei, On 15/01/18 10:41, Wei Yongjun wrote: > In case of error, the function of_platform_device_create() returns > NULL pointer not ERR_PTR(). The IS_ERR() test in the return value > check should be replaced with NULL test. Bother, so it does! Thanks for catching this. Acked-by: Ja

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi gengdongjiu, On 16/12/17 04:47, gengdongjiu wrote: > [...] >> >>> + case ESR_ELx_AET_UER: /* The error has not been propagated */ >>> + /* >>> + * Userspace only handle the guest SError Interrupt(SEI) if >>> the >>> + * error has not been propagated

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi gengdongjiu, On 16/12/17 04:47, gengdongjiu wrote: > [...] >> >>> + case ESR_ELx_AET_UER: /* The error has not been propagated */ >>> + /* >>> + * Userspace only handle the guest SError Interrupt(SEI) if >>> the >>> + * error has not been propagated

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi gengdongjiu, On 15/12/17 03:30, gengdongjiu wrote: > On 2017/12/7 14:37, gengdongjiu wrote: >>> We need to tackle (1) and (3) separately. For (3) we need some API that lets >>> Qemu _trigger_ an SError in the guest, with a specified ESR. But, we don't >>> have >>> a way of migrating pending

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi gengdongjiu, On 15/12/17 03:30, gengdongjiu wrote: > On 2017/12/7 14:37, gengdongjiu wrote: >>> We need to tackle (1) and (3) separately. For (3) we need some API that lets >>> Qemu _trigger_ an SError in the guest, with a specified ESR. But, we don't >>> have >>> a way of migrating pending

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

Hi Will, Marc, On 05/01/18 13:12, 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

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

Hi Will, Marc, On 05/01/18 13:12, 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

Re: [PATCH v2 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs

Hi Marc, Will, (SOB-chain suggests a missing From: tag on this and patch 7) On 05/01/18 13:12, Will Deacon wrote: > Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing > and can theoretically be attacked by malicious code. > > This patch implements a PSCI-based mitigation

Re: [PATCH v2 11/11] arm64: Implement branch predictor hardening for affected Cortex-A CPUs

Hi Marc, Will, (SOB-chain suggests a missing From: tag on this and patch 7) On 05/01/18 13:12, Will Deacon wrote: > Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing > and can theoretically be attacked by malicious code. > > This patch implements a PSCI-based mitigation

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi gengdongjiu, On 07/12/17 06:37, gengdongjiu wrote: > I understand you most idea. > > But In the Qemu one signal type can only correspond to one behavior, can not > correspond to two behaviors, > otherwise Qemu will do not know how to do. > > For the Qemu, if it receives the SIGBUS_MCEERR_AR

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi gengdongjiu, On 07/12/17 06:37, gengdongjiu wrote: > I understand you most idea. > > But In the Qemu one signal type can only correspond to one behavior, can not > correspond to two behaviors, > otherwise Qemu will do not know how to do. > > For the Qemu, if it receives the SIGBUS_MCEERR_AR

Re: [Question ]: Avoid kernel panic when killing an application if happen RAS page table error

Hi gengdongjiu, On 15/12/17 02:00, gengdongjiu wrote: > change the mail title and resend. (please don't do this, we all got the first version) > If the user space application happen page table RAS error,Memory error > handler(memory_failure()) will > do nothing except making a poisoned page

Re: [Question ]: Avoid kernel panic when killing an application if happen RAS page table error

Hi gengdongjiu, On 15/12/17 02:00, gengdongjiu wrote: > change the mail title and resend. (please don't do this, we all got the first version) > If the user space application happen page table RAS error,Memory error > handler(memory_failure()) will > do nothing except making a poisoned page

Re: [RESEND PATCH V2] arm64: fault: avoid send SIGBUS two times

> do_mem_abort() wants to know if we handled the error, we always > call arm64_notify_die() so can always return success. > > Signed-off-by: Dongjiu Geng <gengdong...@huawei.com> Reviewed-by: James Morse <james.mo...@arm.com> Nit: Your 'RESEND V2' and 'V2' are not the sam

Re: [RESEND PATCH V2] arm64: fault: avoid send SIGBUS two times

> do_mem_abort() wants to know if we handled the error, we always > call arm64_notify_die() so can always return success. > > Signed-off-by: Dongjiu Geng Reviewed-by: James Morse Nit: Your 'RESEND V2' and 'V2' are not the same patch. 'RESEND' is to indicate you're reposting exac

Re: [PATCH RESEND] arm64: fault: avoid send SIGBUS two times

Hi gengdongjiu, On 08/12/17 04:43, gengdongjiu wrote: > by the way, I think also change the info.si_code to "BUS_MCEERR_AR" is > better, as shown [1]. > BUS_MCEERR_AR can tell user space "Hardware memory error consumed on a > error; action required". Today its also used as the last-resort.

Re: [PATCH RESEND] arm64: fault: avoid send SIGBUS two times

Hi gengdongjiu, On 08/12/17 04:43, gengdongjiu wrote: > by the way, I think also change the info.si_code to "BUS_MCEERR_AR" is > better, as shown [1]. > BUS_MCEERR_AR can tell user space "Hardware memory error consumed on a > error; action required". Today its also used as the last-resort.

Re: [PATCH RESEND] arm64: fault: avoid send SIGBUS two times

Hi gengdongjiu, Will, On 07/12/17 05:55, gengdongjiu wrote: > On 2017/12/7 0:15, Will Deacon wrote: >>> --- a/arch/arm64/mm/fault.c >>> +++ b/arch/arm64/mm/fault.c >>> @@ -570,7 +570,6 @@ static int do_sea(unsigned long addr, unsigned int esr, >>> struct pt_regs *regs) >>> { >>> struct

Re: [PATCH RESEND] arm64: fault: avoid send SIGBUS two times

Hi gengdongjiu, Will, On 07/12/17 05:55, gengdongjiu wrote: > On 2017/12/7 0:15, Will Deacon wrote: >>> --- a/arch/arm64/mm/fault.c >>> +++ b/arch/arm64/mm/fault.c >>> @@ -570,7 +570,6 @@ static int do_sea(unsigned long addr, unsigned int esr, >>> struct pt_regs *regs) >>> { >>> struct

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi gengdongjiu, On 06/12/17 10:26, gengdongjiu wrote: > On 2017/11/15 0:00, James Morse wrote: >>> +* error has not been propagated >>> +*/ >>> + run->exit_reason = KVM_EXIT_EXCEPTION; >>> + run->ex.excep

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi gengdongjiu, On 06/12/17 10:26, gengdongjiu wrote: > On 2017/11/15 0:00, James Morse wrote: >>> +* error has not been propagated >>> +*/ >>> + run->exit_reason = KVM_EXIT_EXCEPTION; >>> + run->ex.excep

Re: [PATCH v2] arm64: kdump: Avoid to power off nonpanic CPUs

Hi Mathieu, On 21/11/17 19:06, Mathieu Poirier wrote: > On 21 November 2017 at 09:47, James Morse <james.mo...@arm.com> wrote: >> On 18/11/17 09:12, Leo Yan wrote: >>> The upper patch has no issue if enabled crash dump only; but if enabled >>> crash dump and

Re: [PATCH v2] arm64: kdump: Avoid to power off nonpanic CPUs

Hi Mathieu, On 21/11/17 19:06, Mathieu Poirier wrote: > On 21 November 2017 at 09:47, James Morse wrote: >> On 18/11/17 09:12, Leo Yan wrote: >>> The upper patch has no issue if enabled crash dump only; but if enabled >>> crash dump and Coresight debug module for pa

Re: [PATCH v2] arm64: kdump: Avoid to power off nonpanic CPUs

Hi Leo Yan, On 18/11/17 09:12, Leo Yan wrote: > commit a88ce63b642c ("arm64: kexec: have own crash_smp_send_stop() for > crash dump for nonpanic cores") introduces ARM64 architecture function (This commit fixed a bug where the core-code version was used, this didn't save the CPU registers, which

Re: [PATCH v2] arm64: kdump: Avoid to power off nonpanic CPUs

Hi Leo Yan, On 18/11/17 09:12, Leo Yan wrote: > commit a88ce63b642c ("arm64: kexec: have own crash_smp_send_stop() for > crash dump for nonpanic cores") introduces ARM64 architecture function (This commit fixed a bug where the core-code version was used, this didn't save the CPU registers, which

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi Dongjiu Geng, On 10/11/17 19:54, Dongjiu Geng wrote: > If it is not RAS SError, directly inject virtual SError, > which will keep the old way. If it is RAS SError, firstly > let host ACPI module to handle it. > For the ACPI handling, > if the error address is invalid, APEI driver will not >

Re: [PATCH v8 7/7] arm64: kvm: handle SError Interrupt by categorization

Hi Dongjiu Geng, On 10/11/17 19:54, Dongjiu Geng wrote: > If it is not RAS SError, directly inject virtual SError, > which will keep the old way. If it is RAS SError, firstly > let host ACPI module to handle it. > For the ACPI handling, > if the error address is invalid, APEI driver will not >

Re: [PATCH v8 0/7] Support RAS virtualization in KVM

Hi Dongjiu Geng, On 10/11/17 19:54, Dongjiu Geng wrote: > This series patches mainly do below things: > > 1. Trap RAS ERR* registers Accesses to EL2 from Non-secure EL1, >KVM will will do a minimum simulation, there registers are simulated >to RAZ/WI in KVM. > 2. Route synchronous

Re: [PATCH v8 0/7] Support RAS virtualization in KVM

Hi Dongjiu Geng, On 10/11/17 19:54, Dongjiu Geng wrote: > This series patches mainly do below things: > > 1. Trap RAS ERR* registers Accesses to EL2 from Non-secure EL1, >KVM will will do a minimum simulation, there registers are simulated >to RAZ/WI in KVM. > 2. Route synchronous

Re: [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041

Hi Shanker, On 09/11/17 15:22, Shanker Donthineni wrote: > On 11/09/2017 05:08 AM, James Morse wrote: >> On 04/11/17 21:43, Shanker Donthineni wrote: >>> On 11/03/2017 10:11 AM, Robin Murphy wrote: >>>> On 03/11/17 03:27, Shanker Donthineni wrote: >>>>

Re: [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041

Hi Shanker, On 09/11/17 15:22, Shanker Donthineni wrote: > On 11/09/2017 05:08 AM, James Morse wrote: >> On 04/11/17 21:43, Shanker Donthineni wrote: >>> On 11/03/2017 10:11 AM, Robin Murphy wrote: >>>> On 03/11/17 03:27, Shanker Donthineni wrote: >>>>

Re: [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041

Hi Shanker, Robin, On 04/11/17 21:43, Shanker Donthineni wrote: > On 11/03/2017 10:11 AM, Robin Murphy wrote: >> On 03/11/17 03:27, Shanker Donthineni wrote: >>> The ARM architecture defines the memory locations that are permitted >>> to be accessed as the result of a speculative instruction

Re: [PATCH 3/3] arm64: Add software workaround for Falkor erratum 1041

Hi Shanker, Robin, On 04/11/17 21:43, Shanker Donthineni wrote: > On 11/03/2017 10:11 AM, Robin Murphy wrote: >> On 03/11/17 03:27, Shanker Donthineni wrote: >>> The ARM architecture defines the memory locations that are permitted >>> to be accessed as the result of a speculative instruction

Re: [3/3] arm64: Add software workaround for Falkor erratum 1041

Hi Manoj, On 08/11/17 19:05, Manoj Iyer wrote: > On Thu, 2 Nov 2017, Shanker Donthineni wrote: >> The ARM architecture defines the memory locations that are permitted >> to be accessed as the result of a speculative instruction fetch from >> an exception level for which all stages of translation

Re: [3/3] arm64: Add software workaround for Falkor erratum 1041

Hi Manoj, On 08/11/17 19:05, Manoj Iyer wrote: > On Thu, 2 Nov 2017, Shanker Donthineni wrote: >> The ARM architecture defines the memory locations that are permitted >> to be accessed as the result of a speculative instruction fetch from >> an exception level for which all stages of translation

Re: get_online_cpus() from a preemptible() context (bug?)

Hi Peter, On 06/11/17 21:07, Peter Zijlstra wrote: > On Mon, Nov 06, 2017 at 06:51:35PM +0000, James Morse wrote: >>> If you look at percpu_down_read(), you'll note it'll disable preemption >>> before calling __percpu_down_read(). >> >> Yes, this is

Re: get_online_cpus() from a preemptible() context (bug?)

Hi Peter, On 06/11/17 21:07, Peter Zijlstra wrote: > On Mon, Nov 06, 2017 at 06:51:35PM +0000, James Morse wrote: >>> If you look at percpu_down_read(), you'll note it'll disable preemption >>> before calling __percpu_down_read(). >> >> Yes, this is

Re: get_online_cpus() from a preemptible() context (bug?)

Hi Peter, (combining your replies) On 06/11/17 10:32, Peter Zijlstra wrote: > On Fri, Nov 03, 2017 at 02:45:45PM +0000, James Morse wrote: >> I'm trying to work out what stops a thread being pre-empted and migrated >> between >> calling get_online_cpus() and put_online_cp

Re: get_online_cpus() from a preemptible() context (bug?)

Hi Peter, (combining your replies) On 06/11/17 10:32, Peter Zijlstra wrote: > On Fri, Nov 03, 2017 at 02:45:45PM +0000, James Morse wrote: >> I'm trying to work out what stops a thread being pre-empted and migrated >> between >> calling get_online_cpus() and put_online_cp

[PATCH 3/4] 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> Acked-by: Will Deacon <will.dea...@arm.com> Tested-by:

[PATCH 3/4] 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 Acked-by: Will Deacon Tested-by: Tyler Baicar --- arch/arm64/include/asm/acpi.h | 12

[PATCH 4/4] 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> Reviewed-by: Borislav Petkov <b...@suse.de> --- arch/x86

[PATCH 1/4] ACPI / APEI: Replace ioremap_page_range() with fixmap

ang Wu <fengguang...@intel.com> Suggested-by: Linus Torvalds <torva...@linux-foundation.org> Signed-off-by: James Morse <james.mo...@arm.com> Reviewed-by: Borislav Petkov <b...@suse.de> Tested-by: Tyler Baicar <tbai...@codeaurora.org> Tested-by: Toshi Kani <toshi.k...

[PATCH 4/4] 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 Reviewed-by: Borislav Petkov --- arch/x86/kernel/acpi/apei.c | 5 - include/acpi/apei.h

[PATCH 1/4] ACPI / APEI: Replace ioremap_page_range() with fixmap

Torvalds Signed-off-by: James Morse Reviewed-by: Borislav Petkov Tested-by: Tyler Baicar Tested-by: Toshi Kani [ For the arm64 bits: ] Acked-by: Will Deacon [ For the x86 bits: ] Acked-by: Ingo Molnar --- Changes since RFC: * Added #ifdefs around the entries in fixmap.h * Added a paragraph

[PATCH 2/4] ACPI / APEI: Remove ghes_ioremap_area

Now that nothing is using the ghes_ioremap_area pages, rip them out. Signed-off-by: James Morse <james.mo...@arm.com> Reviewed-by: Borislav Petkov <b...@suse.de> Tested-by: Tyler Baicar <tbai...@codeaurora.org> --- drivers/acpi/apei/ghes.c | 39 ++---

[PATCH 2/4] ACPI / APEI: Remove ghes_ioremap_area

Now that nothing is using the ghes_ioremap_area pages, rip them out. Signed-off-by: James Morse Reviewed-by: Borislav Petkov Tested-by: Tyler Baicar --- drivers/acpi/apei/ghes.c | 39 ++- 1 file changed, 2 insertions(+), 37 deletions(-) diff --git

[PATCH 0/4] Switch GHES ioremap_page_range() to use fixmap

patches for improved history I've tried to be clear with who-acked-what when merging the patches. For reference, the arch-acks are here: https://lkml.org/lkml/2017/11/2/254 https://lkml.org/lkml/2017/10/31/780 Thanks, James Morse (4): ACPI / APEI: Replace ioremap_page_range() with fixmap

[PATCH 0/4] Switch GHES ioremap_page_range() to use fixmap

patches for improved history I've tried to be clear with who-acked-what when merging the patches. For reference, the arch-acks are here: https://lkml.org/lkml/2017/11/2/254 https://lkml.org/lkml/2017/10/31/780 Thanks, James Morse (4): ACPI / APEI: Replace ioremap_page_range() with fixmap

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

On 01/11/17 18:20, Kani, Toshimitsu wrote: > On Wed, 2017-11-01 at 16:30 +0100, Borislav Petkov wrote: >> On Wed, Nov 01, 2017 at 02:58:33PM +0000, James Morse wrote: >>> Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI? >> AFAIK, the

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

On 01/11/17 18:20, Kani, Toshimitsu wrote: > On Wed, 2017-11-01 at 16:30 +0100, Borislav Petkov wrote: >> On Wed, Nov 01, 2017 at 02:58:33PM +0000, James Morse wrote: >>> Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI? >> AFAIK, the

Re: [RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

Hi gengdongjiu On 02/11/17 12:01, gengdongjiu wrote: > James Morse wrote: >> Can I take that as a 'Tested-by:'? >> >> These tags also let us record who has a system that can test changes to this >> driver. > > sure. > Thanks for the fixing. > Qian

Re: [RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

Hi gengdongjiu On 02/11/17 12:01, gengdongjiu wrote: > James Morse wrote: >> Can I take that as a 'Tested-by:'? >> >> These tags also let us record who has a system that can test changes to this >> driver. > > sure. > Thanks for the fixing. > Qian

get_online_cpus() from a preemptible() context (bug?)

Hi Thomas, Peter, I'm trying to work out what stops a thread being pre-empted and migrated between calling get_online_cpus() and put_online_cpus(). According to __percpu_down_read(), its the pre-empt count: > * Due to having preemption disabled the decrement happens on > * the same CPU as the

get_online_cpus() from a preemptible() context (bug?)

Hi Thomas, Peter, I'm trying to work out what stops a thread being pre-empted and migrated between calling get_online_cpus() and put_online_cpus(). According to __percpu_down_read(), its the pre-empt count: > * Due to having preemption disabled the decrement happens on > * the same CPU as the

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

Hi Linus, On 31/10/17 15:52, Linus Torvalds wrote: > On Tue, Oct 31, 2017 at 8:38 AM, James Morse <james.mo...@arm.com> wrote: >> 7 files changed, 30 insertions(+), 85 deletions(-) > > Lovely. > > I obviously can't test it, but it looks fine. I *would* suggest ju

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

Hi Linus, On 31/10/17 15:52, Linus Torvalds wrote: > On Tue, Oct 31, 2017 at 8:38 AM, James Morse wrote: >> 7 files changed, 30 insertions(+), 85 deletions(-) > > Lovely. > > I obviously can't test it, but it looks fine. I *would* suggest just > making the &quo

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

Hi guys, (+CC: Chen Gong and Huang Ying from the git log of [0]) On 31/10/17 15:38, James Morse wrote: > RFC as I've only build-tested this on x86. Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI? > Any more testing would be welcome. ('ls /sys/firmware/acpi/

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

Hi guys, (+CC: Chen Gong and Huang Ying from the git log of [0]) On 31/10/17 15:38, James Morse wrote: > RFC as I've only build-tested this on x86. Does anyone have an x86 machine that does firmware-first using NOTIFY_NMI? > Any more testing would be welcome. ('ls /sys/firmware/acpi/

Re: [RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

Hi gengdonjiu, On 01/11/17 04:13, gengdongjiu wrote: > On 2017/10/31 23:38, James Morse wrote: >> CC'd people I've seen posting CPER log fragments, could you give this a >> test on your platforms? > Thanks for the fixing, not found obviously issue. Can I take that as a 'Tested

Re: [RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

Hi gengdonjiu, On 01/11/17 04:13, gengdongjiu wrote: > On 2017/10/31 23:38, James Morse wrote: >> CC'd people I've seen posting CPER log fragments, could you give this a >> test on your platforms? > Thanks for the fixing, not found obviously issue. Can I take that as a 'Tested

Re: [PATCH v1 0/3] manually add Error Synchronization Barrier at exception handler entry and exit

Hi Dongjiu Geng, On 01/11/17 19:14, Dongjiu Geng wrote: > Some hardware platform can support RAS Extension, but not support IESB, > such as Huawei's platform, so software need to insert Synchronization Barrier > operations at exception handler entry. > > This series patches are based on James's

Re: [PATCH v1 0/3] manually add Error Synchronization Barrier at exception handler entry and exit

Hi Dongjiu Geng, On 01/11/17 19:14, Dongjiu Geng wrote: > Some hardware platform can support RAS Extension, but not support IESB, > such as Huawei's platform, so software need to insert Synchronization Barrier > operations at exception handler entry. > > This series patches are based on James's

[RFC/RFT PATCH 4/6] ACPI / APEI: Remove ghes_ioremap_area

Now that nothing is using the ghes_ioremap_area pages, rip them out. Signed-off-by: James Morse <james.mo...@arm.com> --- drivers/acpi/apei/ghes.c | 39 ++- 1 file changed, 2 insertions(+), 37 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/driver

[RFC/RFT PATCH 4/6] ACPI / APEI: Remove ghes_ioremap_area

Now that nothing is using the ghes_ioremap_area pages, rip them out. Signed-off-by: James Morse --- drivers/acpi/apei/ghes.c | 39 ++- 1 file changed, 2 insertions(+), 37 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index

[RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

() for arm64 and __set_pte_vaddr() for x86. In each case its the same as the respective arch_apei_flush_tlb_one(). Reported-by: Fengguang Wu <fengguang...@intel.com> Suggested-by: Linus Torvalds <torva...@linux-foundation.org> Signed-off-by: James Morse <james.mo...@arm.com> CC:

[RFC/RFT PATCH 3/6] ACPI / APEI: Replace ioremap_page_range() with fixmap

() for arm64 and __set_pte_vaddr() for x86. In each case its the same as the respective arch_apei_flush_tlb_one(). Reported-by: Fengguang Wu Suggested-by: Linus Torvalds Signed-off-by: James Morse CC: Tyler Baicar CC: Dongjiu Geng CC: Xie XiuQi --- CC'd people I've seen posting CPER log fragments

<    2   3   4   5   6   7   8   9   10   11   >