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, th
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_onli
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
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
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
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 a
irst three 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_rang
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 only
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.
&g
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 i
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
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/firm
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
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
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
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
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
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
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
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 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
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
to a
> invalid value.
This paragraph keeps cropping up. Who expects an address 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: Dong
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
> I
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
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 origi
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 vds
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.
>> (
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
> +
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
>
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_MCEERR_A* from
hat does CONFIG_HIST_TRIGGERS 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
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, w
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 lo
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
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
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. Howeve
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_ACPI_APEI_SEA
>
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
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 A
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
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 t
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 betw
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
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 KVM's
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 handl
dditional 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 &
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 er
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
ion can 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
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 External
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
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 f06e51
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 in
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
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 that
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 in-b
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] s
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
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 than
it is up to that 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
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
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, gengdongj
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
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 actio
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
Hi Yury,
On 04/06/17 13:00, Yury Norov wrote:
> ILP32 has context-related structures different from both aarch32 and
> aarch64/lp64. In this patch compat_arch_ptrace() renamed to
> compat_a32_ptrace(), and compat_arch_ptrace() only makes choice between
> compat_a32_ptrace() and new compat_ilp32_pt
Hi Yury,
On 04/06/17 13:00, Yury Norov wrote:
> Signed-off-by: Yury Norov
Can I offer a body for the commit message:
ILP32 needs to mix 32bit struct siginfo and 64bit sigframe for its signal
handlers. Move the existing compat code for copying siginfo to user space and
manipulating signal masks i
Hi Yury,
On 04/06/17 12:59, Yury Norov wrote:
> From: Andrew Pinski
>
> In this patchset ILP32 ABI support is added. Additionally to AARCH32,
> which is binary-compatible with ARM, ILP32 is (mostly) ABI-compatible.
>
> From now, AARCH32_EL0 (former COMPAT) config option means the support of
>
Hi Yury,
On 04/06/17 13:00, Yury Norov wrote:
> From: Andrew Pinski
>
> Add a separate syscall-table for ILP32, which dispatches either to native
> LP64 system call implementation or to compat-syscalls, as appropriate.
(I'm still reading through this series trying to understand it, but spotted
Hi gengdongjiu,
On 05/05/17 13:31, gengdongjiu wrote:
> when guest OS happen an SEA, My current solution is shown below:
>
> (1) host EL3 firmware firstly handle the SEA error and generate the CPER
> record.
> (2) EL3 firmware separately copy the esr_el3, elr_el3, SPSR_el3,
> far_el3 to the esr_
Hi gengdongjiu,
On 10/05/17 09:44, gengdongjiu wrote:
> On 2017/5/9 1:28, James Morse wrote:
>>>> (hwpoison for KVM is a corner case as Qemu's memory effectively has two
>>>> users,
>>>> Qemu and KVM. This isn't the example of how user-space get
Hi Tyler,
On 08/05/17 20:59, Baicar, Tyler wrote:
> On 5/8/2017 11:28 AM, James Morse wrote:
>> I was tidying up the masking/unmasking in entry.S, something I wasn't aware
>> of
>> that leads to a bug:
>> entry.S will unmask interrupts for instruction/data aborts
Hi Christoffer,
On 08/05/17 18:54, Christoffer Dall wrote:
> On Mon, May 08, 2017 at 06:28:02PM +0100, James Morse wrote:
> I must admit I am losing track of exactly what this proposed API was
> supposed to do.
There are two, and we keep jumping between them!
This is about two not
Hi gengdongjiu,
On 04/05/17 18:20, gengdongjiu wrote:
>> On 30/04/17 06:37, Dongjiu Geng wrote:
>>> Handle kvmtool's detection for RAS extension, because sometimes
>>> the APP needs to know the CPU's capacity
>>
>>> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
>>> index d9e9697..10
Hi Tyler,
On 19/04/17 00:05, Tyler Baicar wrote:
> ARM APEI extension proposal added SEA (Synchronous External Abort)
> notification type for ARMv8.
> Add a new GHES error source handling function for SEA. If an error
> source's notification type is SEA, then this function can be registered
> into
Hi gengdongjiu,
On 04/05/17 17:52, gengdongjiu wrote:
> 2017-05-04 23:42 GMT+08:00 gengdongjiu :
>> On 30/04/17 06:37, Dongjiu Geng wrote:
>>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>>> index 105b6ab..a96594f 100644
>>> --- a/arch/arm/kvm/mmu.c
>>> +++ b/arch/arm/kvm/mmu.c
>>> +stati
Hi Xiongfeng Wang,
On 28/04/17 03:55, Xiongfeng Wang wrote:
>>> >> It is ok to just ignore the process following the ESB instruction in
>>> >> el0_sync, because the process will be sent SIGBUS signal.
>> >
>> > I don't understand. How will Linux know the process caused an error if we
>> > neithe
Hi Wang Xiongfeng,
On 21/04/17 12:33, Xiongfeng Wang wrote:
> On 2017/4/20 16:52, James Morse wrote:
>> On 19/04/17 03:37, Xiongfeng Wang wrote:
>>> On 2017/4/18 18:51, James Morse wrote:
>>>> The host expects to receive physical SError Interrupts. The ARM-ARM
Hi Wang Xiongfeng,
On 19/04/17 03:37, Xiongfeng Wang wrote:
> On 2017/4/18 18:51, James Morse wrote:
>> The host expects to receive physical SError Interrupts. The ARM-ARM doesn't
>> describe a way to inject these as they are generated by the CPU.
>>
>> Am I right
Hi Wang Xiongfeng,
On 18/04/17 02:09, Xiongfeng Wang wrote:
> I have some confusion about the RAS feature when VHE is enabled. Does RAS
> spec support
> the situation when VHE is enabled. When VHE is disabled, the hyperviosr
> delegates the error
> exception to EL1 by setting HCR_EL2.VSE to 1, a
Hi Xie XiuQi,
On 30/03/17 11:31, Xie XiuQi wrote:
> From: Wang Xiongfeng
>
> Since SEI is asynchronous, the error data has been consumed. So we must
> suppose that all the memory data current process can write are
> contaminated. If the process doesn't have shared writable pages, the
> process w
to read-only memory at virtual
> address 08a11f10
I also gave this a spin on software-models with PAN and PAN+UAO, and TTBR0-PAN
on Juno.
With that hunk omitted:
Reviewed-by: James Morse
Tested-by: James Morse
Thanks,
James
ting, replacement patches, etc. are very welcome.
For the two "arm64: " patches:
Reviewed-by: James Morse
Thanks,
James
Hi Xie XiuQi,
On 30/03/17 11:31, Xie XiuQi wrote:
> On arm64 platform, SEI may interrupt code which had interrupts masked.
> But SEI could be masked, so it's not treated as NMI, however SEA is
> treated as NMI.
>
> So, the memory area used to transfer hardware error information from
> BIOS to Li
Hi Xie XiuQi,
On 30/03/17 11:31, Xie XiuQi wrote:
> ARM APEI extension proposal added SEI (asynchronous SError interrupt)
> notification type for ARMv8.
>
> Add a new GHES error source handling function for SEI. In firmware
> first mode, if an error source's notification type is SEI. Then GHES
>
Hi Tyler,
On 29/03/17 16:54, Tyler Baicar wrote:
> If a HED type error occurs prior to GHES probing, the kernel will
> never report the error. The HED driver will see that no notifiers
> are registered, and clear the interrupt.
>
> This becomes a more serious problem with firmware that supports
>
Hi gengdongjiu,
On 28/03/17 13:16, gengdongjiu wrote:
> On 2017/3/28 19:54, Achin Gupta wrote:
>> On Tue, Mar 28, 2017 at 01:23:28PM +0200, Christoffer Dall wrote:
>>> On Tue, Mar 28, 2017 at 11:48:08AM +0100, James Morse wrote:
>>>> On the host, part of UEFI is
Hi Peter,
On 28/03/17 12:33, Peter Maydell wrote:
> On 28 March 2017 at 12:23, Christoffer Dall wrote:
>> On Tue, Mar 28, 2017 at 11:48:08AM +0100, James Morse wrote:
>>> On the host, part of UEFI is involved to generate the CPER records.
>>> In a guest?, I don'
Hi Tyler,
On 21/03/17 22:47, Tyler Baicar wrote:
> Currently external aborts are unsupported by the guest abort
> handling. Add handling for SEAs so that the host kernel reports
> SEAs which occur in the guest kernel.
Looks good,
Can we squash the APEI changes into the patch that added them? Thi
Hi Christoffer,
(CC: Leif and Achin who know more about how UEFI fits into this picture)
On 21/03/17 19:39, Christoffer Dall wrote:
> On Tue, Mar 21, 2017 at 07:11:44PM +0000, James Morse wrote:
>> On 21/03/17 11:34, Christoffer Dall wrote:
>>> On Tue, Mar 21, 2017 a
Hi Dongjiu Geng,
On 23/03/17 13:01, Dongjiu Geng wrote:
> when the pfn is KVM_PFN_ERR_HWPOISON, it indicates to send
> SIGBUS signal from KVM's fault-handling code to qemu, qemu
> can handle this signal according to the fault address.
I'm afraid I beat you to it on this one:
https://www.spinics.n
Hi Punit,
On 01/02/17 21:38, Tyler Baicar wrote:
> From: "Jonathan (Zhixiong) Zhang"
>
> If ACPI_APEI and MEMORY_FAILURE is configured, select
> ACPI_APEI_MEMORY_FAILURE. This enables memory failure recovery
> when such memory failure is reported through ACPI APEI. APEI
> (ACPI Platform Error In
Hi gengdongjiu
On 22/03/17 13:37, gengdongjiu wrote:
> On 2017/3/21 21:10, James Morse wrote:
>> On 21/03/17 06:32, gengdongjiu wrote:
>>> so for both SEA and SEI, do you prefer to below steps?
>>> EL0/EL1 SEI/SEA ---> EL3 firmware first handle --> EL2 hyperv
Hi Wang Xiongfeng,
On 22/03/17 02:46, Xiongfeng Wang wrote:
>> Guests are a special case as QEMU may never access the faulty memory itself,
>> so
>> it won't receive the 'late' signal. It looks like ARM/arm64 KVM lacks support
>> for KVM_PFN_ERR_HWPOISON which sends SIGBUS from KVM's fault-handli
Hi Christoffer,
On 21/03/17 11:34, Christoffer Dall wrote:
> On Tue, Mar 21, 2017 at 02:32:29PM +0800, gengdongjiu wrote:
>> On 2017/3/20 23:08, James Morse wrote:
>>>>>> On 20/03/17 07:55, Dongjiu Geng wrote:
>>>>>>> In the RAS implementation
Hi,
On 21/03/17 06:32, gengdongjiu wrote:
> On 2017/3/20 23:08, James Morse wrote:
>> On 20/03/17 13:58, Marc Zyngier wrote:
>>> On 20/03/17 12:28, gengdongjiu wrote:
>>>> On 2017/3/20 19:24, Marc Zyngier wrote:
>>>>> On 20/03/17 07:55, Dongjiu
Hi Dongjiu Geng,
On 20/03/17 13:58, Marc Zyngier wrote:
> On 20/03/17 12:28, gengdongjiu wrote:
>> On 2017/3/20 19:24, Marc Zyngier wrote:
>>> Please include James Morse on anything RAS related, as he's already
>>> looking at related patches.
(Thanks Marc,)
>
Hi Xie XiuQi,
On 20/03/17 07:48, Xie XiuQi wrote:
> On 2017/3/14 17:45, James Morse wrote:
>> On 08/03/17 04:09, Xie XiuQi wrote:
>>> Add ghes handling for SEI so that the host kernel could parse and
>>> report detailed error information for SEI which occur in the guest
Hi Tyler,
On 06/03/17 20:44, Tyler Baicar wrote:
> ARM APEI extension proposal added SEA (Synchronous External Abort)
> notification type for ARMv8.
> Add a new GHES error source handling function for SEA. If an error
> source's notification type is SEA, then this function can be registered
> into
501 - 600 of 707 matches
Mail list logo
