We are about to disturb the header soup. This header uses struct pid
and struct pid_namespace. Include their header.
Signed-off-by: James Morse
Reviewed-by: Reinette Chatre
---
include/linux/resctrl.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/resctrl.h b/include/linux
mbm_handle_overflow() and cqm_handle_limbo() are both provided with
the domain's work_struct when called, but use get_domain_from_cpu()
to find the domain, along with the appropriate error handling.
container_of() saves some list walking and bitmap testing, use that
instead.
Signed-off-by:
est
needed for Haswell, but as it always sets this value to 1, it will
never match.
CC: Babu Moger
CC: Reinette Chatre
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/resctrl/core.c| 14
arch/x86/kernel/cpu/resctrl/ctrlmondata.c | 39 ++-
arch/x86/kernel/c
The comment in rdtgroup_init() refers to the non existent function
rdt_mount(), which has now been renamed rdt_get_tree(). Fix the
comment.
Signed-off-by: James Morse
Reviewed-by: Reinette Chatre
---
arch/x86/kernel/cpu/resctrl/rdtgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Hi guys,
On 12/05/2020 19:05, Dan Williams wrote:
> On Tue, May 12, 2020 at 9:28 AM Rafael J. Wysocki
> wrote:
>> Dan,
>>
>> Has this been addressed in the v2?
>
> No, this looks like a case I was concerned about, i.e. the GHES code
> is not being completely careful to avoid calling potentially
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 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 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 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 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 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
ting, replacement patches, etc. are very welcome.
For the two "arm64: " patches:
Reviewed-by: James Morse
Thanks,
James
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
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
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 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 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 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 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 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
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 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
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 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 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 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 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 a
arts immediately.
Reported-by: Xie XiuQi
Signed-off-by: James Morse
CC: Xie XiuQi
CC: gengdongjiu
---
mm/memory-failure.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 4b80ccee4535..14f44d841e8b 100644
--- a/mm/m
Hi gengdongjiu,
On 12/02/18 10:19, gengdongjiu wrote:
> On 2018/2/10 1:44, James Morse wrote:
>> The point? We can't know what a CPU without the RAS extensions puts in there.
>>
>> Why Does this matter? When migrating a pending SError we have to know the
>> di
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 firmw
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
>&
Hi Dongjiu Geng,
On 22/02/18 18:02, Dongjiu Geng wrote:
> The RAS SError Syndrome can be Implementation-Defined,
> arm64_is_ras_serror() is used to judge whether it is RAS SError,
> but arm64_is_ras_serror() does not include this judgement. In order
> to avoid function name confusion, we rename th
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
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 som
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
> gene
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 pani
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
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 fl
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
> 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
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 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 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 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,
(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 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
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 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
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,
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 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
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 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
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 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:
> 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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 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 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 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 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 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 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 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 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 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
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:
> 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 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
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 sigin
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 a
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 fetch
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:
>>>>
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
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 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. Thi
f the
requested CPU is not online.
Add disable_nonboot_cpus() as an inline function that has the existing
behaviour.
Signed-off-by: James Morse
Cc: Rafael J. Wysocki
---
An alternative is to provide two functions calling a common function,
but this would mean spilling the cpu_maps_update_begin()
ate arch-header,
use hibernate_resume_nonboot_cpu_disable() to direct which CPU we should
resume on based on the MPIDR of the CPU we hibernated on. This allows us to
hibernate/resume on any CPU, even if the logical numbers have been
shuffled by kexec.
Signed-off-by: James Morse
Cc: Mark Rutla
33]
[ 80.860246] CPU3 is up
[ 80.873337] PM: noirq restore of devices complete after 1.434 msecs
[ 80.880381] PM: early restore of devices complete after 0.701 msecs
[ 81.231471] PM: restore of devices complete after 71.157 msecs
[ 81.238336] Restarting tasks ... done.
root@ubuntu:~#
-
d-off-by: James Morse
Acked-by: Catalin Marinas
---
This patch should be merged via the same tree as patch 1.
arch/arm64/kernel/hibernate.c | 26 --
1 file changed, 26 deletions(-)
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index 9fcf2fc
Commit-ID: 7e947926fc3bfa095644c2933ec209128cbfd61e
Gitweb: http://git.kernel.org/tip/7e947926fc3bfa095644c2933ec209128cbfd61e
Author: James Morse
AuthorDate: Mon, 19 Sep 2016 18:29:15 +0100
Committer: Thomas Gleixner
CommitDate: Mon, 19 Sep 2016 21:07:12 +0200
irqchip/gicv3: Silence
Commit-ID: 727653d6ce7103b245eb8041f55dd5885f4c3289
Gitweb: http://git.kernel.org/tip/727653d6ce7103b245eb8041f55dd5885f4c3289
Author: James Morse
AuthorDate: Mon, 19 Sep 2016 18:29:15 +0100
Committer: Thomas Gleixner
CommitDate: Tue, 20 Sep 2016 01:43:23 +0200
irqchip/gicv3: Silence
The following commit has been merged into the x86/cache branch of tip:
Commit-ID: 41215b7947f1b1b86fd77a7bebd2320599aea7bd
Gitweb:
https://git.kernel.org/tip/41215b7947f1b1b86fd77a7bebd2320599aea7bd
Author:James Morse
AuthorDate:Wed, 08 Jul 2020 16:39:26
Committer
The following commit has been merged into the x86/cache branch of tip:
Commit-ID: 316e7f901f5aedb415c72d1eedd7de0846238dd0
Gitweb:
https://git.kernel.org/tip/316e7f901f5aedb415c72d1eedd7de0846238dd0
Author:James Morse
AuthorDate:Wed, 08 Jul 2020 16:39:28
Committer
The following commit has been merged into the x86/cache branch of tip:
Commit-ID: f995801ba3a0660cb352c8beb794379c82781ca3
Gitweb:
https://git.kernel.org/tip/f995801ba3a0660cb352c8beb794379c82781ca3
Author:James Morse
AuthorDate:Wed, 08 Jul 2020 16:39:23
Committer
The following commit has been merged into the x86/cache branch of tip:
Commit-ID: a21a4391f20c0ab45db452e22bc3e8afe8b36e46
Gitweb:
https://git.kernel.org/tip/a21a4391f20c0ab45db452e22bc3e8afe8b36e46
Author:James Morse
AuthorDate:Wed, 08 Jul 2020 16:39:24
Committer
601 - 700 of 707 matches
Mail list logo
