Hi gengdongjiu,
On 01/06/18 08:21, gengdongjiu wrote:
> On 2018/6/1 0:51, James Morse wrote:
>> On 31/05/18 12:01, Mark Rutland wrote:
>>> In do_serror() we already handle nmi_{enter,exit}(), so there's no need
>>> for that here.
>>
>> Even
Hi gengdongjiu,
On 01/06/18 08:21, gengdongjiu wrote:
> On 2018/6/1 0:51, James Morse wrote:
>> On 31/05/18 12:01, Mark Rutland wrote:
>>> In do_serror() we already handle nmi_{enter,exit}(), so there's no need
>>> for that here.
>>
>> Even
Hi Jun,
On 06/06/18 05:39, Jun Yao wrote:
> Migrate swapper_pg_dir and tramp_pg_dir. And their virtual addresses
> do not correlate with kernel's address.
This is all to make 'KSMA' harder, where an single arbitrary write is used to
add a block mapping to the page-tables, giving the attacker
Hi Jun,
On 06/06/18 05:39, Jun Yao wrote:
> Migrate swapper_pg_dir and tramp_pg_dir. And their virtual addresses
> do not correlate with kernel's address.
This is all to make 'KSMA' harder, where an single arbitrary write is used to
add a block mapping to the page-tables, giving the attacker
Hi Dongjiu Geng,
Please only put 'RESEND' in the subject if the patch content is identical.
This patch is not the same as v4.
On 08/06/18 20:48, Dongjiu Geng wrote:
> For the migrating VMs, user space may need to know the exception
> state. For example, in the machine A, KVM make an SError
Hi Dongjiu Geng,
Please only put 'RESEND' in the subject if the patch content is identical.
This patch is not the same as v4.
On 08/06/18 20:48, Dongjiu Geng wrote:
> For the migrating VMs, user space may need to know the exception
> state. For example, in the machine A, KVM make an SError
Hi Dongjiu Geng,
On 09/06/18 13:40, Marc Zyngier wrote:
> On Fri, 08 Jun 2018 20:48:40 +0100, Dongjiu Geng wrote:
>> For the migrating VMs, user space may need to know the exception
>> state. For example, in the machine A, KVM make an SError pending,
>> when migrate to B, KVM also needs to pend
Hi Dongjiu Geng,
On 09/06/18 13:40, Marc Zyngier wrote:
> On Fri, 08 Jun 2018 20:48:40 +0100, Dongjiu Geng wrote:
>> For the migrating VMs, user space may need to know the exception
>> state. For example, in the machine A, KVM make an SError pending,
>> when migrate to B, KVM also needs to pend
Hi Vishun,
(CC: +linux-arm-kernel list)
On 05/06/18 14:12, Andy Shevchenko wrote:
> On Thu, May 31, 2018 at 1:01 PM, Vishnu Motghare
> wrote:
>> My understanding is each CPU getting its own IRQ stack. So is it
>> possible to print the stack uses of each IRQ handler?
The stacks are per-cpu not
Hi Vishun,
(CC: +linux-arm-kernel list)
On 05/06/18 14:12, Andy Shevchenko wrote:
> On Thu, May 31, 2018 at 1:01 PM, Vishnu Motghare
> wrote:
>> My understanding is each CPU getting its own IRQ stack. So is it
>> possible to print the stack uses of each IRQ handler?
The stacks are per-cpu not
Hi Jun Yao,
On 01/06/18 09:08, Jun Yao wrote:
> Introduce __pa_swapper_pg_dir to save physical address of
> swapper_pg_dir. And pass it as an argument to __enable_mmu().
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index b0853069702f..e3bb44b4b6c6 100644
> ---
Hi Jun Yao,
On 01/06/18 09:08, Jun Yao wrote:
> Introduce __pa_swapper_pg_dir to save physical address of
> swapper_pg_dir. And pass it as an argument to __enable_mmu().
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index b0853069702f..e3bb44b4b6c6 100644
> ---
Hi Mark, Dongjiu Geng,
On 31/05/18 12:01, Mark Rutland wrote:
> In do_serror() we already handle nmi_{enter,exit}(), so there's no need
> for that here.
Even better: nmi_enter() has a BUG_ON(in_nmi()).
> TBH, I don't understand why do_sea() does that conditionally today.
> Unless there's some
Hi Mark, Dongjiu Geng,
On 31/05/18 12:01, Mark Rutland wrote:
> In do_serror() we already handle nmi_{enter,exit}(), so there's no need
> for that here.
Even better: nmi_enter() has a BUG_ON(in_nmi()).
> TBH, I don't understand why do_sea() does that conditionally today.
> Unless there's some
Hi Akashi,
On 18/05/18 11:39, AKASHI Takahiro wrote:
> On Tue, May 15, 2018 at 06:11:15PM +0100, James Morse wrote:
>> On 25/04/18 07:26, AKASHI Takahiro wrote:
>>> Enabling crash dump (kdump) includes
>>> * prepare contents of ELF header of a core dump file
Hi Akashi,
On 18/05/18 11:39, AKASHI Takahiro wrote:
> On Tue, May 15, 2018 at 06:11:15PM +0100, James Morse wrote:
>> On 25/04/18 07:26, AKASHI Takahiro wrote:
>>> Enabling crash dump (kdump) includes
>>> * prepare contents of ELF header of a core dump file
Hi Akashi,
On 18/05/18 08:42, AKASHI Takahiro wrote:
> On Fri, May 18, 2018 at 04:11:35PM +0900, AKASHI Takahiro wrote:
>> On Tue, May 15, 2018 at 05:20:00PM +0100, James Morse wrote:
>>> On 25/04/18 07:26, AKASHI Takahiro wrote:
>>>> diff --git a/arch/arm64/kerne
Hi Akashi,
On 18/05/18 08:42, AKASHI Takahiro wrote:
> On Fri, May 18, 2018 at 04:11:35PM +0900, AKASHI Takahiro wrote:
>> On Tue, May 15, 2018 at 05:20:00PM +0100, James Morse wrote:
>>> On 25/04/18 07:26, AKASHI Takahiro wrote:
>>>> diff --git a/arch/arm64/kerne
Hi Baoquan,
On 17/05/18 03:15, Baoquan He wrote:
> On 05/17/18 at 10:10am, Baoquan He wrote:
>> On 05/07/18 at 02:59pm, AKASHI Takahiro wrote:
>>> On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
>>>> On 25/04/18 07:26, AKASHI Takahiro wrote:
>>>
Hi Baoquan,
On 17/05/18 03:15, Baoquan He wrote:
> On 05/17/18 at 10:10am, Baoquan He wrote:
>> On 05/07/18 at 02:59pm, AKASHI Takahiro wrote:
>>> On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
>>>> On 25/04/18 07:26, AKASHI Takahiro wrote:
>>>
Hi Akashi,
On 15/05/18 18:11, James Morse wrote:
> On 25/04/18 07:26, AKASHI Takahiro wrote:
>> Enabling crash dump (kdump) includes
>> * prepare contents of ELF header of a core dump file, /proc/vmcore,
>> using crash_prepare_elf64_headers(), and
>> * add two dev
Hi Akashi,
On 15/05/18 18:11, James Morse wrote:
> On 25/04/18 07:26, AKASHI Takahiro wrote:
>> Enabling crash dump (kdump) includes
>> * prepare contents of ELF header of a core dump file, /proc/vmcore,
>> using crash_prepare_elf64_headers(), and
>> * add two dev
Hi Akashi,
On 15/05/18 18:11, James Morse wrote:
> On 25/04/18 07:26, AKASHI Takahiro wrote:
>> Enabling crash dump (kdump) includes
>> * prepare contents of ELF header of a core dump file, /proc/vmcore,
>> using crash_prepare_elf64_headers(), and
>> * add two dev
Hi Akashi,
On 15/05/18 18:11, James Morse wrote:
> On 25/04/18 07:26, AKASHI Takahiro wrote:
>> Enabling crash dump (kdump) includes
>> * prepare contents of ELF header of a core dump file, /proc/vmcore,
>> using crash_prepare_elf64_headers(), and
>> * add two dev
Hi Akashi,
On 15/05/18 06:13, AKASHI Takahiro wrote:
> On Fri, May 11, 2018 at 06:07:06PM +0100, James Morse wrote:
>> On 07/05/18 08:21, AKASHI Takahiro wrote:
>>> On Tue, May 01, 2018 at 06:46:11PM +0100, James Morse wrote:
>>>> On 25/04/18 07:26, AKASHI Ta
Hi Akashi,
On 15/05/18 06:13, AKASHI Takahiro wrote:
> On Fri, May 11, 2018 at 06:07:06PM +0100, James Morse wrote:
>> On 07/05/18 08:21, AKASHI Takahiro wrote:
>>> On Tue, May 01, 2018 at 06:46:11PM +0100, James Morse wrote:
>>>> On 25/04/18 07:26, AKASHI Ta
Hi guys,
(CC: +RobH, devicetree list)
On 25/04/18 07:26, AKASHI Takahiro wrote:
> Enabling crash dump (kdump) includes
> * prepare contents of ELF header of a core dump file, /proc/vmcore,
> using crash_prepare_elf64_headers(), and
> * add two device tree properties,
Hi guys,
(CC: +RobH, devicetree list)
On 25/04/18 07:26, AKASHI Takahiro wrote:
> Enabling crash dump (kdump) includes
> * prepare contents of ELF header of a core dump file, /proc/vmcore,
> using crash_prepare_elf64_headers(), and
> * add two device tree properties,
Hi Akashi,
On 25/04/18 07:26, AKASHI Takahiro wrote:
> Enabling crash dump (kdump) includes
> * prepare contents of ELF header of a core dump file, /proc/vmcore,
> using crash_prepare_elf64_headers(), and
> * add two device tree properties, "linux,usable-memory-range" and
>
Hi Akashi,
On 25/04/18 07:26, AKASHI Takahiro wrote:
> Enabling crash dump (kdump) includes
> * prepare contents of ELF header of a core dump file, /proc/vmcore,
> using crash_prepare_elf64_headers(), and
> * add two device tree properties, "linux,usable-memory-range" and
>
Hi Akashi,
On 25/04/18 07:26, AKASHI Takahiro wrote:
> load_other_segments() is expected to allocate and place all the necessary
> memory segments other than kernel, including initrd and device-tree
> blob (and elf core header for crash).
> While most of the code was borrowed from kexec-tools'
Hi Akashi,
On 25/04/18 07:26, AKASHI Takahiro wrote:
> load_other_segments() is expected to allocate and place all the necessary
> memory segments other than kernel, including initrd and device-tree
> blob (and elf core header for crash).
> While most of the code was borrowed from kexec-tools'
Hi Akashi,
On 15/05/18 05:35, AKASHI Takahiro wrote:
> On Mon, May 07, 2018 at 02:59:07PM +0900, AKASHI Takahiro wrote:
>> On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
>>> On 25/04/18 07:26, AKASHI Takahiro wrote:
>>>> We need to prevent fi
Hi Akashi,
On 15/05/18 05:35, AKASHI Takahiro wrote:
> On Mon, May 07, 2018 at 02:59:07PM +0900, AKASHI Takahiro wrote:
>> On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
>>> On 25/04/18 07:26, AKASHI Takahiro wrote:
>>>> We need to prevent fi
Hi Akashi,
On 15/05/18 05:45, AKASHI Takahiro wrote:
> On Fri, May 11, 2018 at 06:03:49PM +0100, James Morse wrote:
>> On 07/05/18 06:22, AKASHI Takahiro wrote:
>>> On Tue, May 01, 2018 at 06:46:06PM +0100, James Morse wrote:
>>>> On 25/04/18 07:26, AKASHI Takahiro
Hi Akashi,
On 15/05/18 05:45, AKASHI Takahiro wrote:
> On Fri, May 11, 2018 at 06:03:49PM +0100, James Morse wrote:
>> On 07/05/18 06:22, AKASHI Takahiro wrote:
>>> On Tue, May 01, 2018 at 06:46:06PM +0100, James Morse wrote:
>>>> On 25/04/18 07:26, AKASHI Takahiro
Hi Akashi,
On 07/05/18 08:21, AKASHI Takahiro wrote:
> On Tue, May 01, 2018 at 06:46:11PM +0100, James Morse wrote:
>> On 25/04/18 07:26, AKASHI Takahiro wrote:
>>> This patch provides kexec_file_ops for "Image"-format kernel. In this
>>> implementation, a
Hi Akashi,
On 07/05/18 08:21, AKASHI Takahiro wrote:
> On Tue, May 01, 2018 at 06:46:11PM +0100, James Morse wrote:
>> On 25/04/18 07:26, AKASHI Takahiro wrote:
>>> This patch provides kexec_file_ops for "Image"-format kernel. In this
>>> implementation, a
Hi Akashi,
On 07/05/18 06:22, AKASHI Takahiro wrote:
> On Tue, May 01, 2018 at 06:46:06PM +0100, James Morse wrote:
>> On 25/04/18 07:26, AKASHI Takahiro wrote:
>>> diff --git a/arch/arm64/kernel/machine_kexec.c
>>> b/arch/arm64/kernel/machine_kexec.c
>>> ind
Hi Akashi,
On 07/05/18 06:22, AKASHI Takahiro wrote:
> On Tue, May 01, 2018 at 06:46:06PM +0100, James Morse wrote:
>> On 25/04/18 07:26, AKASHI Takahiro wrote:
>>> diff --git a/arch/arm64/kernel/machine_kexec.c
>>> b/arch/arm64/kernel/machine_kexec.c
>>> ind
Hi Suzuki,
On 27/03/18 14:15, Suzuki K Poulose wrote:
> We set VTCR_EL2 very early during the stage2 init and don't
> touch it ever. This is fine as we had a fixed IPA size. This
> patch changes the behavior to set the VTCR for a given VM,
> depending on its stage2 table. The common configuration
Hi Suzuki,
On 27/03/18 14:15, Suzuki K Poulose wrote:
> We set VTCR_EL2 very early during the stage2 init and don't
> touch it ever. This is fine as we had a fixed IPA size. This
> patch changes the behavior to set the VTCR for a given VM,
> depending on its stage2 table. The common configuration
Hi Suzuki,
Nit: KVM in the subject line?
On 27/03/18 14:15, Suzuki K Poulose wrote:
> Add a helper to convert ID_AA64MMFR0_EL1:PARange to they physical
> size shift. Limit the size to the maximum supported by the kernel.
> We are about to move the user of this code and this helps to
> keep the
Hi Suzuki,
Nit: KVM in the subject line?
On 27/03/18 14:15, Suzuki K Poulose wrote:
> Add a helper to convert ID_AA64MMFR0_EL1:PARange to they physical
> size shift. Limit the size to the maximum supported by the kernel.
> We are about to move the user of this code and this helps to
> keep the
Hi Akashi,
On 25/04/18 07:26, AKASHI Takahiro wrote:
> We need to prevent firmware-reserved memory regions, particularly EFI
> memory map as well as ACPI tables, from being corrupted by loading
> kernel/initrd (or other kexec buffers). We also want to support memory
> allocation in top-down
Hi Akashi,
On 25/04/18 07:26, AKASHI Takahiro wrote:
> We need to prevent firmware-reserved memory regions, particularly EFI
> memory map as well as ACPI tables, from being corrupted by loading
> kernel/initrd (or other kexec buffers). We also want to support memory
> allocation in top-down
Hi Akashi,
On 25/04/18 07:26, AKASHI Takahiro wrote:
> On arm64, purugatory would do almosty nothing. So just invoke secondary
> kernel directy by jumping into its entry code.
(Nits: purgatory, almost, directly)
> While, in this case, cpu_soft_restart() must be called with dtb address
> in the
Hi Akashi,
On 25/04/18 07:26, AKASHI Takahiro wrote:
> On arm64, purugatory would do almosty nothing. So just invoke secondary
> kernel directy by jumping into its entry code.
(Nits: purgatory, almost, directly)
> While, in this case, cpu_soft_restart() must be called with dtb address
> in the
Hi Akashi,
On 25/04/18 07:26, AKASHI Takahiro wrote:
> This patch provides kexec_file_ops for "Image"-format kernel. In this
> implementation, a binary is always loaded with a fixed offset identified
> in text_offset field of its header.
> diff --git a/arch/arm64/include/asm/kexec.h
Hi Akashi,
On 25/04/18 07:26, AKASHI Takahiro wrote:
> Change this function from static to global so that arm64 can implement
> its own arch_kimage_file_post_load_cleanup() later using
> kexec_image_post_load_cleanup_default().
Do we need to call kexec_image_post_load_cleanup_default()? All it
Hi Akashi,
On 25/04/18 07:26, AKASHI Takahiro wrote:
> Change this function from static to global so that arm64 can implement
> its own arch_kimage_file_post_load_cleanup() later using
> kexec_image_post_load_cleanup_default().
Do we need to call kexec_image_post_load_cleanup_default()? All it
Hi Akashi,
On 25/04/18 07:26, AKASHI Takahiro wrote:
> This patch provides kexec_file_ops for "Image"-format kernel. In this
> implementation, a binary is always loaded with a fixed offset identified
> in text_offset field of its header.
> diff --git a/arch/arm64/include/asm/kexec.h
Hi Alex,
On 04/16/2018 10:59 PM, Alex G. wrote:
> On 04/13/2018 11:38 AM, James Morse wrote:
>> This assumes a cache-invalidate will clear the error, which I don't
think we're
>> guaranteed on arm.
>> It also destroys any adjacent data, "everyone's happy" i
Hi Alex,
On 04/16/2018 10:59 PM, Alex G. wrote:
> On 04/13/2018 11:38 AM, James Morse wrote:
>> This assumes a cache-invalidate will clear the error, which I don't
think we're
>> guaranteed on arm.
>> It also destroys any adjacent data, "everyone's happy" i
Hi Alex,
(I haven't read through all this yet, just on this one:)
On 04/19/2018 03:57 PM, Alex G. wrote:
> Maybe it's better move the AER handling to NMI/IRQ context, since
> ghes_handle_aer() is only scheduling the real AER andler, and is irq
> safe. I'm scratching my head about why we're
Hi Alex,
(I haven't read through all this yet, just on this one:)
On 04/19/2018 03:57 PM, Alex G. wrote:
> Maybe it's better move the AER handling to NMI/IRQ context, since
> ghes_handle_aer() is only scheduling the real AER andler, and is irq
> safe. I'm scratching my head about why we're
Hi Alex,
On 09/04/18 19:11, Alex G. wrote:
> On 04/06/2018 01:24 PM, James Morse wrote:
> Do you have any ETA on when your SEA patches are going to make it
> upstream? There's not much point in updating my patchset if it's going
> to conflict with your work.
The SE
Hi Alex,
On 09/04/18 19:11, Alex G. wrote:
> On 04/06/2018 01:24 PM, James Morse wrote:
> Do you have any ETA on when your SEA patches are going to make it
> upstream? There's not much point in updating my patchset if it's going
> to conflict with your work.
The SE
Hi gengdongjiu,
On 12/04/18 06:00, gengdongjiu wrote:
> 2018-02-16 1:55 GMT+08:00 James Morse <james.mo...@arm.com>:
>> On 05/02/18 11:24, gengdongjiu wrote:
>>>> Is the emulated SError routed following the routing rules for HCR_EL2.{AMO,
>>>> TGE}
Hi gengdongjiu,
On 12/04/18 06:00, gengdongjiu wrote:
> 2018-02-16 1:55 GMT+08:00 James Morse :
>> On 05/02/18 11:24, gengdongjiu wrote:
>>>> Is the emulated SError routed following the routing rules for HCR_EL2.{AMO,
>>>> TGE}?
>>>
>>> Yes, it
Hi gengdongjiu,
On 12/04/18 07:09, gengdongjiu wrote:
> On 2018/4/10 22:15, James Morse wrote:
>> On 09/04/18 22:36, Dongjiu Geng wrote:
>>> 1. Detect whether KVM can set set guest SError syndrome
>>> 2. Support to Set VSESR_EL2 and inject SError by user space.
&g
Hi gengdongjiu,
On 12/04/18 07:09, gengdongjiu wrote:
> On 2018/4/10 22:15, James Morse wrote:
>> On 09/04/18 22:36, Dongjiu Geng wrote:
>>> 1. Detect whether KVM can set set guest SError syndrome
>>> 2. Support to Set VSESR_EL2 and inject SError by user space.
&g
Hi Dongjiu Geng,
On 09/04/18 22:36, Dongjiu Geng wrote:
> 1. Detect whether KVM can set set guest SError syndrome
> 2. Support to Set VSESR_EL2 and inject SError by user space.
> 3. Support live migration to keep SError pending state and VSESR_EL2 value.
> 4. ACPI 6.1 adds support for NOTIFY_SEI
Hi Dongjiu Geng,
On 09/04/18 22:36, Dongjiu Geng wrote:
> 1. Detect whether KVM can set set guest SError syndrome
> 2. Support to Set VSESR_EL2 and inject SError by user space.
> 3. Support live migration to keep SError pending state and VSESR_EL2 value.
> 4. ACPI 6.1 adds support for NOTIFY_SEI
Hi Dongjiu Geng,
On 09/04/18 22:36, Dongjiu Geng wrote:
> This new IOCTL exports user-invisible states related to SError.
> Together with appropriate user space changes, it can inject
> SError with specified syndrome to guest by setup kvm_vcpu_events
> value.
> Also it can support live
Hi Dongjiu Geng,
On 09/04/18 22:36, Dongjiu Geng wrote:
> This new IOCTL exports user-invisible states related to SError.
> Together with appropriate user space changes, it can inject
> SError with specified syndrome to guest by setup kvm_vcpu_events
> value.
> Also it can support live
efine KVM_CAP_ARM_INJECT_SERROR_ESR 153
>
> #ifdef KVM_CAP_IRQ_ROUTING
(patch 1&2 should probably be swapped around, as on its own this does thing).
Reviewed-by: James Morse <james.mo...@arm.com>
Thanks,
James
efine KVM_CAP_ARM_INJECT_SERROR_ESR 153
>
> #ifdef KVM_CAP_IRQ_ROUTING
(patch 1&2 should probably be swapped around, as on its own this does thing).
Reviewed-by: James Morse
Thanks,
James
Hi Alex,
On 04/04/18 20:49, Alex G. wrote:
> On 04/04/2018 11:53 AM, James Morse wrote:
>>>> How do we know we will survive this trip?
>>>
>>> We don't.
>>
>> Isn't that even worse than panic()ing? (No output, followed by a watchdog
>> rebo
Hi Alex,
On 04/04/18 20:49, Alex G. wrote:
> On 04/04/2018 11:53 AM, James Morse wrote:
>>>> How do we know we will survive this trip?
>>>
>>> We don't.
>>
>> Isn't that even worse than panic()ing? (No output, followed by a watchdog
>> rebo
Hi Mark,
On 06/04/18 18:22, Mark Rutland wrote:
> Digging a bit, I also thing that our ct_user_exit and ct_user_enter
> usage is on dodgy ground today.
[...]
> I think similar applies to SDEI; we don't negotiate with RCU prior to
> invoking handlers, which might need RCU.
The arch code's
Hi Mark,
On 06/04/18 18:22, Mark Rutland wrote:
> Digging a bit, I also thing that our ct_user_exit and ct_user_enter
> usage is on dodgy ground today.
[...]
> I think similar applies to SDEI; we don't negotiate with RCU prior to
> invoking handlers, which might need RCU.
The arch code's
Hi Yury,
On 05/04/18 18:17, Yury Norov wrote:
> This series enables delaying of kernel memory synchronization
> for CPUs running in extended quiescent state (EQS) till the exit
> of that state.
>
> ARM64 uses IPI mechanism to notify all cores in SMP system that
> kernel text is changed; and IPI
Hi Yury,
On 05/04/18 18:17, Yury Norov wrote:
> This series enables delaying of kernel memory synchronization
> for CPUs running in extended quiescent state (EQS) till the exit
> of that state.
>
> ARM64 uses IPI mechanism to notify all cores in SMP system that
> kernel text is changed; and IPI
Hi Yury,
On 05/04/18 18:17, Yury Norov wrote:
> Kernel text patching framework relies on IPI to ensure that other
> SMP cores observe the change. Target core calls isb() in IPI handler
(Odd, if its just to synchronize the CPU, taking the IPI should be enough).
> path, but not at the beginning
Hi Yury,
On 05/04/18 18:17, Yury Norov wrote:
> Kernel text patching framework relies on IPI to ensure that other
> SMP cores observe the change. Target core calls isb() in IPI handler
(Odd, if its just to synchronize the CPU, taking the IPI should be enough).
> path, but not at the beginning
Hi Alex,
On 04/04/18 16:33, Alex G. wrote:
> On 04/04/2018 02:18 AM, James Morse wrote:
>> On 03/04/18 18:08, Alexandru Gagniuc wrote:
>>> BIOSes like to send NMIs for a number of silly reasons often deemed
>>> to be "fatal". For example pin bounce during
Hi Alex,
On 04/04/18 16:33, Alex G. wrote:
> On 04/04/2018 02:18 AM, James Morse wrote:
>> On 03/04/18 18:08, Alexandru Gagniuc wrote:
>>> BIOSes like to send NMIs for a number of silly reasons often deemed
>>> to be "fatal". For example pin bounce during
Hi Alexandru,
On 03/04/18 18:08, Alexandru Gagniuc wrote:
> BIOSes like to send NMIs for a number of silly reasons often deemed
> to be "fatal". For example pin bounce during a PCIE hotplug/unplug
> might cause the link to go down and retrain, with fatal PCI errors
> being generated while the
Hi Alexandru,
On 03/04/18 18:08, Alexandru Gagniuc wrote:
> BIOSes like to send NMIs for a number of silly reasons often deemed
> to be "fatal". For example pin bounce during a PCIE hotplug/unplug
> might cause the link to go down and retrain, with fatal PCI errors
> being generated while the
Hi Suzuki,
On 27/03/18 14:15, Suzuki K Poulose wrote:
> We set VTCR_EL2 very early during the stage2 init and don't
> touch it ever. This is fine as we had a fixed IPA size. This
> patch changes the behavior to set the VTCR for a given VM,
> depending on its stage2 table. The common configuration
Hi Suzuki,
On 27/03/18 14:15, Suzuki K Poulose wrote:
> We set VTCR_EL2 very early during the stage2 init and don't
> touch it ever. This is fine as we had a fixed IPA size. This
> patch changes the behavior to set the VTCR for a given VM,
> depending on its stage2 table. The common configuration
Hi gengdongjiu,
On 08/03/18 06:18, gengdongjiu wrote:
> Hi James,
>sorry for my late response due to chines new year.
Happy new year,
> 2018-02-16 1:55 GMT+08:00 James Morse <james.mo...@arm.com>:
>> On 12/02/18 10:19, gengdongjiu wrote:
>>> On 201
Hi gengdongjiu,
On 08/03/18 06:18, gengdongjiu wrote:
> Hi James,
>sorry for my late response due to chines new year.
Happy new year,
> 2018-02-16 1:55 GMT+08:00 James Morse :
>> On 12/02/18 10:19, gengdongjiu wrote:
>>> On 2018/2/10 1:44, James Morse wrote:
>&
Hi Dongjiu Geng,
On 03/03/18 16:09, Dongjiu Geng wrote:
> Before user space injects a SError, it needs to know whether it can
> specify the guest Exception Syndrome, so KVM should tell user space
> whether it has such capability.
> diff --git a/Documentation/virtual/kvm/api.txt
>
Hi Dongjiu Geng,
On 03/03/18 16:09, Dongjiu Geng wrote:
> Before user space injects a SError, it needs to know whether it can
> specify the guest Exception Syndrome, so KVM should tell user space
> whether it has such capability.
> diff --git a/Documentation/virtual/kvm/api.txt
>
Hi Dongjiu Geng,
On 03/03/18 16:09, Dongjiu Geng wrote:
> RAS Extension provides VSESR_EL2 register to specify
> virtual SError syndrome value, this patch adds a new
> IOCTL to export user-invisible states related to
> SError exceptions. User space can setup the
> kvm_vcpu_events to inject
Hi Dongjiu Geng,
On 03/03/18 16:09, Dongjiu Geng wrote:
> RAS Extension provides VSESR_EL2 register to specify
> virtual SError syndrome value, this patch adds a new
> IOCTL to export user-invisible states related to
> SError exceptions. User space can setup the
> kvm_vcpu_events to inject
Hi Dongjiu Geng,
On 03/03/18 16:09, Dongjiu Geng wrote:
> Export one API to specify virtual SEI syndrome value
> for guest, and add a helper to get the VSESR_EL2 value.
This patch adds two helpers that nothing calls... its not big, please merge it
with the patch that uses these.
> diff --git
Hi Dongjiu Geng,
On 03/03/18 16:09, Dongjiu Geng wrote:
> Export one API to specify virtual SEI syndrome value
> for guest, and add a helper to get the VSESR_EL2 value.
This patch adds two helpers that nothing calls... its not big, please merge it
with the patch that uses these.
> diff --git
Hi gengdongjiu,
On 26/02/18 16:13, gengdongjiu wrote:
> 2018-02-24 1:58 GMT+08:00 James Morse <james.mo...@arm.com>:
>> On 22/02/18 18:02, Dongjiu Geng wrote:
>>> The RAS SError Syndrome can be Implementation-Defined,
>>> arm64_is_ras_serror() is used
Hi gengdongjiu,
On 26/02/18 16:13, gengdongjiu wrote:
> 2018-02-24 1:58 GMT+08:00 James Morse :
>> 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,
Hi York,
You have a DT binding in here, please CC the devicetree list. You're touching
code under arch/arm64, so you need the arm list too. get_maintainer.pl will take
your patch and give you the list of which lists and maintainers to CC.
(I've added those lists, the full patch is here:
Hi York,
You have a DT binding in here, please CC the devicetree list. You're touching
code under arch/arm64, so you need the arm list too. get_maintainer.pl will take
your patch and give you the list of which lists and maintainers to CC.
(I've added those lists, the full patch is here:
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
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
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
>> differe
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
>> differe
<xiexi...@huawei.com>
Signed-off-by: James Morse <james.mo...@arm.com>
CC: Xie XiuQi <xiexi...@huawei.com>
CC: gengdongjiu <gengdong...@huawei.com>
---
mm/memory-failure.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/mm/memory-failu
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/memory-failure.c
+++ b/mm/memory-fai
501 - 600 of 1082 matches
Mail list logo
