Hello,
On 15/01/2019 06:25, Masami Hiramatsu wrote:
> Use arch_populate_kprobe_blacklist() instead of
> arch_within_kprobe_blacklist() so that we can see the full
> blacklisted symbols under the debugfs.
> diff --git a/arch/arm64/kernel/probes/kprobes.c
> b/arch/arm64/kernel/probes/kprobes.c
>
is as its where do_debug_exception() lives, which kprobes
depends on for single-stepping.
Reviewed-by: James Morse
Thanks!
James
Hi guys,
On 14/01/2019 16:12, Julien Thierry wrote:
> On 14/01/2019 15:56, Catalin Marinas wrote:
>> On Tue, Jan 08, 2019 at 02:07:19PM +, Julien Thierry wrote:
>>> When using VHE, the host needs to clear HCR_EL2.TGE bit in order
>>> to interract with guest TLBs, switching from EL2&0
Hi Peter,
On 14/01/2019 13:16, Peter Zijlstra wrote:
> On Fri, Jan 11, 2019 at 06:32:58PM +0000, James Morse wrote:
>> On 10/01/2019 20:12, Peter Zijlstra wrote:
>>> On Thu, Jan 10, 2019 at 06:25:57PM +, James Morse wrote:
>>> The thing is, everything non-maskab
Hi Peter,
On 10/01/2019 20:12, Peter Zijlstra wrote:
> On Thu, Jan 10, 2019 at 06:25:57PM +0000, James Morse wrote:
>
>> On arm64 if all the RAS and psuedo-NMI patches land, our worst-case
>> interleaving
>> jumps to at least 7. The culprit is APEI using spinlocks to
Hi,
On 09/01/2019 02:05, Masami Hiramatsu wrote:
> On Tue, 8 Jan 2019 17:13:36 +
> James Morse wrote:
>> On 08/01/2019 02:39, Masami Hiramatsu wrote:
>>> On Thu, 3 Jan 2019 17:05:18 +
>>> James Morse wrote:
>>>> On 17/12/2018 06:40, Masami H
Hi Wladislav,
On 09/01/2019 14:44, Wiebe, Wladislav (Nokia - DE/Ulm) wrote:
>> From: James Morse
>> Sent: Tuesday, January 08, 2019 6:57 PM
>> On 08/01/2019 10:42, Borislav Petkov wrote:
>>> So the first thing to figure out here is how generic is
Hi Longman, Zhenzhong,
On 10/01/2019 14:43, Waiman Long wrote:
> On 01/10/2019 03:02 AM, Zhenzhong Duan wrote:
>> There is a question confused me for days. Appreciate an answer.
>>
>> In below code, the comment says we never have more than 4 nested
>> contexts.
>>
>> What happen if debug and mce
Hi Greg,
On 01/08/2019 06:12 PM, gre...@linuxfoundation.org wrote:
On Tue, Jan 08, 2019 at 05:57:24PM +, James Morse wrote:
diff --git a/drivers/edac/cortex_a15_l2_async_edac.c
b/drivers/edac/cortex_a15_l2_async_edac.c
new file mode 100644
index ..26252568e961
--- /dev/null
Hi Boris, Wladislav,
On 08/01/2019 10:42, Borislav Petkov wrote:
> + James and leaving in the rest for reference.
(thanks!)
> So the first thing to figure out here is how generic is this and if
> so, to make it a cortex_a15_edac.c driver which contains all the RAS
> functionality for A15.
Hi!
On 08/01/2019 02:39, Masami Hiramatsu wrote:
> On Thu, 3 Jan 2019 17:05:18 +
> James Morse wrote:
>> On 17/12/2018 06:40, Masami Hiramatsu wrote:
>>> Move extable address check into arch_prepare_kprobe() from
>>> arch_within_kprobe_blacklist().
>>
&
Hi Amit,
On 18/12/2018 07:56, Amit Daniel Kachhap wrote:
> This is a runtime feature and can be enabled by --ptrauth option.
It took me a little while to realise this was a kvmtool patch. could you put
something in the patch-subject to make this obvious? e.g:
Hi Amit,
On 18/12/2018 07:56, Amit Daniel Kachhap wrote:
> According to userspace settings, pointer authentication cpufeature
> is enabled/disabled from guests.
This reads like the guest is changing something in the host. Isn't this hiding
the id-register values from the guest?
> diff --git
Hi Amit,
On 18/12/2018 07:56, Amit Daniel Kachhap wrote:
> This feature will allow the KVM guest to allow the handling of
> pointer authentication instructions or to treat them as undefined
> if not set. It uses the existing vcpu API KVM_ARM_VCPU_INIT to
> supply this parameter instead of
Hi Amit,
On 18/12/2018 07:56, Amit Daniel Kachhap wrote:
> When pointer authentication is supported, a guest may wish to use it.
> This patch adds the necessary KVM infrastructure for this to work, with
> a semi-lazy context switch of the pointer auth state.
>
> Pointer authentication feature is
Hi Amit,
On 18/12/2018 07:56, Amit Daniel Kachhap wrote:
> When restoring HCR_EL2 for the host, KVM uses HCR_HOST_VHE_FLAGS, which
> is a constant value. This works today, as the host HCR_EL2 value is
> always the same, but this will get in the way of supporting extensions
> that require HCR_EL2
t; be always false.
So it does!
Reviewed-by: James Morse
Thanks
James
> diff --git a/arch/arm64/kernel/probes/kprobes.c
> b/arch/arm64/kernel/probes/kprobes.c
> index b2d4b7428ebc..1dae500d0a81 100644
> --- a/arch/arm64/kernel/probes/kprobes.c
> +++ b/arch/arm64/kernel/
Hi!
On 17/12/2018 06:40, Masami Hiramatsu wrote:
> Move extable address check into arch_prepare_kprobe() from
> arch_within_kprobe_blacklist().
I'm trying to work out the pattern for what should go in the blacklist, and what
should be rejected by the arch code.
It seems address-ranges should be
Hi Nicolas,
On 03/12/2018 12:25, Nicolas Saenz Julienne wrote:
> On Fri, 2018-11-30 at 18:31 +0000, James Morse wrote:
>> On 26/11/2018 12:15, Nicolas Saenz Julienne wrote:
>>> After finding a "firmware" dt node arm_sdei tries to match it's
>>> compatible
On 21/12/2018 11:17, Rafael J. Wysocki wrote:
> On Thursday, December 20, 2018 8:24:47 PM CET Borislav Petkov wrote:
>> + James.
Thanks,
>> On Wed, Dec 19, 2018 at 11:50:52AM -0500, David Arcari wrote:
>>> From: Lenny Szubowicz
>>>
>>> In __ghes_panic() clear the block status in the APEI
Hi Peter,
On 19/12/2018 19:02, Peter Maydell wrote:
> On Mon, 17 Dec 2018 at 15:56, James Morse wrote:
>> I don't think this really matters. Its only the NMIlike notifications that
>> the
>> guest doesn't have to register or poll. The ones we support today extend the
>
!read_sysreg_s(SYS_PSTATE_PAN);
> + }
> +
> + return false;
> +}
(Reading the SCTLR bit is a bit of a heavy-hammer, as suggested elsewhere on the
thread, can we use alternatives_applied here?)
It may be worth splitting this into three patches, so the 'unsafe' bits can be
merged without the debug option.
Either way, for the unsafe parts:
Reviewed-by: James Morse
Thanks!
James
Hi guys,
On 10/12/2018 14:59, Catalin Marinas wrote:
> On Fri, Dec 07, 2018 at 08:38:11AM +, Julien Thierry wrote:
>> On 12/06/2018 06:25 PM, Catalin Marinas wrote:
>>> On Mon, Dec 03, 2018 at 01:55:18PM +, Julien Thierry wrote:
diff --git a/arch/arm64/include/asm/uaccess.h
this
extensions: there are at least three platforms out there that do!
On 15/12/2018 00:12, gengdongjiu wrote:
>> On Fri, 14 Dec 2018 at 13:56, James Morse wrote:
>>> On 14/12/2018 10:15, Dongjiu Geng wrote:
>>>> When user space do memory recovery, it will check whether
Hi Peter,
On 14/12/2018 14:33, Peter Maydell wrote:
> On Fri, 14 Dec 2018 at 13:56, James Morse wrote:
>> On 14/12/2018 10:15, Dongjiu Geng wrote:
>>> When user space do memory recovery, it will check whether KVM and
>>> guest support the error recovery, only when bot
Hi Steve,
On 15/12/2018 03:00, Steven Rostedt wrote:
> On Thu, 13 Dec 2018 17:09:35 +
> James Morse wrote:
>> I gave this branch a spin, but I hit the WARN_ON() fairly easily:
>
> Thanks for testing!
>
> Can you see if this patch fixes it for you?
> diff --gi
Hi Dongjiu Geng,
On 14/12/2018 10:15, Dongjiu Geng wrote:
> When user space do memory recovery, it will check whether KVM and
> guest support the error recovery, only when both of them support,
> user space will do the error recovery. This patch exports this
> capability of KVM to user space.
I
Hi Steven,
On 10/12/2018 19:30, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> [
> Folks, I'm working on rewriting the function graph tracer. In order to
> do so, some changes need to be done that affect architecture specific
> code. I'm only able to compile test these
Hi Qian,
On 13/12/2018 05:22, Qian Cai wrote:
> On this HPE Apollo 70 arm64 server with 256 CPUs, triggering a crash
> dump just hung. It has 4 threads on each core. Each 2-core share a same
> L1 and L2 caches, so that is 8 CPUs shares those. All CPUs share a same
> L3 cache.
>
> It turned out
Hi Akashi,
On 11/12/2018 06:17, AKASHI, Takahiro wrote:
> On Fri, Dec 07, 2018 at 10:12:47AM +0000, James Morse wrote:
>> On 06/12/2018 15:54, Will Deacon wrote:
>>> On Thu, Dec 06, 2018 at 08:47:04AM -0600, Rob Herring wrote:
>>>> On Wed, Nov 14, 2018 at 11:52
these the crash-kernel
overwrites the previous kernel's memory during startup.
Add a check to refuse crash image loading.
Signed-off-by: James Morse
---
Context: http://lore.kernel.org/r/20181206155424.ga4...@arm.com
arch/arm64/kernel/kexec_image.c | 4
1 file changed, 4 insertions(+)
diff --git
Hi Akashi, Will,
On 06/12/2018 15:54, Will Deacon wrote:
> On Thu, Dec 06, 2018 at 08:47:04AM -0600, Rob Herring wrote:
>> On Wed, Nov 14, 2018 at 11:52 PM AKASHI Takahiro
>> wrote:
>>>
>>> Added function, fdt_setprop_reg(), will be used later to handle
>>> kexec-specific property in arm64's
Hi Catalin,
On 04/12/2018 18:09, Catalin Marinas wrote:
> On Mon, Nov 12, 2018 at 11:57:12AM +, Julien Thierry wrote:
>> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
>> index 5f4d9ac..66344cd 100644
>> --- a/arch/arm64/kernel/traps.c
>> +++ b/arch/arm64/kernel/traps.c
>>
Hi Catalin,
On 04/12/2018 18:09, Catalin Marinas wrote:
> On Mon, Nov 12, 2018 at 11:57:12AM +, Julien Thierry wrote:
>> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
>> index 5f4d9ac..66344cd 100644
>> --- a/arch/arm64/kernel/traps.c
>> +++ b/arch/arm64/kernel/traps.c
>>
Hi Yury,
On 27/11/2018 12:33, Yury Norov wrote:
> On Fri, Aug 24, 2018 at 11:44:59AM +0100, James Morse wrote:
>> ARM have some upcoming CPU features that are similar to Intel RDT. Resctrl
>> is the defacto ABI for this sort of thing, but it lives under arch/x86.
>>
>&g
Hi Yury,
On 27/11/2018 12:33, Yury Norov wrote:
> On Fri, Aug 24, 2018 at 11:44:59AM +0100, James Morse wrote:
>> ARM have some upcoming CPU features that are similar to Intel RDT. Resctrl
>> is the defacto ABI for this sort of thing, but it lives under arch/x86.
>>
>&g
Hi gengdongjiu,
On 21/11/2018 08:10, gengdongjiu wrote:
> On 2018/11/20 2:05, James Morse wrote:
>> On 17/11/2018 15:41, gengdongjiu wrote:
>>> In the current kernel, it only handles three kinds of error, which is
>>> memory error, PCIE device and ARM process. But now t
Hi gengdongjiu,
On 21/11/2018 08:10, gengdongjiu wrote:
> On 2018/11/20 2:05, James Morse wrote:
>> On 17/11/2018 15:41, gengdongjiu wrote:
>>> In the current kernel, it only handles three kinds of error, which is
>>> memory error, PCIE device and ARM process. But now t
Nicolas Saenz Julienne
Thanks!, I agree this is unwarranted.
Is there a tool that picks these up? I remember sparse giving me a headache, but
I don't remember this one... I probably cargo-culted it from somewhere else.
Acked-by: James Morse
Thanks,
James
> ---
> drivers/firmware/arm_sd
Nicolas Saenz Julienne
Thanks!, I agree this is unwarranted.
Is there a tool that picks these up? I remember sparse giving me a headache, but
I don't remember this one... I probably cargo-culted it from somewhere else.
Acked-by: James Morse
Thanks,
James
> ---
> drivers/firmware/arm_sd
Hi gengdongjiu,
On 17/11/2018 15:41, gengdongjiu wrote:
> In the current kernel, it only handles three kinds of error, which is
> memory error, PCIE device and ARM process. But now the SMMU already
> support the RAS, how to handle the SMMU RAS error in the kernel?
What errors are being detected
Hi gengdongjiu,
On 17/11/2018 15:41, gengdongjiu wrote:
> In the current kernel, it only handles three kinds of error, which is
> memory error, PCIE device and ARM process. But now the SMMU already
> support the RAS, how to handle the SMMU RAS error in the kernel?
What errors are being detected
Hi Paolo!
On 08/10/2018 16:11, Paolo Pisati wrote:
> This on my dragonboard 410c:
>
> ...
> [0.170657] WARNING: CPU: 2 PID: 1 at arch/arm64/kernel/setup.c:271
> reserve_memblock_reserved_regions+0xd4/0x150
> [0.170666] Modules linked in:
> [0.170680] CPU: 2 PID: 1 Comm: swapper/0
Hi Paolo!
On 08/10/2018 16:11, Paolo Pisati wrote:
> This on my dragonboard 410c:
>
> ...
> [0.170657] WARNING: CPU: 2 PID: 1 at arch/arm64/kernel/setup.c:271
> reserve_memblock_reserved_regions+0xd4/0x150
> [0.170666] Modules linked in:
> [0.170680] CPU: 2 PID: 1 Comm: swapper/0
Hi Babu,
On 24/09/18 20:19, Moger, Babu wrote:
> Enables QOS feature on AMD.
> Following QoS sub-features are supported in AMD if the underlying
> hardware supports it.
> - L3 Cache allocation enforcement
> - L3 Cache occupancy monitoring
> - L3 Code-Data Prioritization support
> - Memory
Hi Babu,
On 24/09/18 20:19, Moger, Babu wrote:
> Enables QOS feature on AMD.
> Following QoS sub-features are supported in AMD if the underlying
> hardware supports it.
> - L3 Cache allocation enforcement
> - L3 Cache occupancy monitoring
> - L3 Code-Data Prioritization support
> - Memory
Hi guys,
On 03/10/18 21:09, Moger, Babu wrote:
> On 10/03/2018 01:52 PM, Fenghua Yu wrote:
>> On Tue, Oct 02, 2018 at 07:16:23PM +, Moger, Babu wrote:
>>> On 10/02/2018 01:46 PM, Fenghua Yu wrote:
I don't see the name 'RDT' (Resource Director Technology) in the
spec "AMD64
Hi guys,
On 03/10/18 21:09, Moger, Babu wrote:
> On 10/03/2018 01:52 PM, Fenghua Yu wrote:
>> On Tue, Oct 02, 2018 at 07:16:23PM +, Moger, Babu wrote:
>>> On 10/02/2018 01:46 PM, Fenghua Yu wrote:
I don't see the name 'RDT' (Resource Director Technology) in the
spec "AMD64
re
>>> making the functional changes. The first few patches(1-6) renames and
>>> re-organizes the sources in preparation. Rest of the patches(7-10) adds
>>> support for AMD QoS features.
>>
>> On the first glance this all looks sensible, but there is work in progr
re
>>> making the functional changes. The first few patches(1-6) renames and
>>> re-organizes the sources in preparation. Rest of the patches(7-10) adds
>>> support for AMD QoS features.
>>
>> On the first glance this all looks sensible, but there is work in progr
| el0_svc+0x8/0xc
| Code: 90007b60 f946e000 cb000273 b2400673 (f9000293)
| ---[ end trace 7bf2d2ffce498c7a ]---
| Kernel panic - not syncing: Fatal exception
The below patch fixes it: I'll post it properly shortly...
---%<---
Author: Jame
| el0_svc+0x8/0xc
| Code: 90007b60 f946e000 cb000273 b2400673 (f9000293)
| ---[ end trace 7bf2d2ffce498c7a ]---
| Kernel panic - not syncing: Fatal exception
The below patch fixes it: I'll post it properly shortly...
---%<---
Author: Jame
Hi Mark,
On 24/09/18 14:34, Mark Rutland wrote:
> On Mon, Sep 17, 2018 at 12:43:30PM +0800, Jun Yao wrote:
>> Create the initial page table in the init_pg_dir. And update the
>> init_mm.pgd to make sure that pgd_offset_k() works correctly. When
>> the final page table is created, we redirect the
Hi Mark,
On 24/09/18 14:34, Mark Rutland wrote:
> On Mon, Sep 17, 2018 at 12:43:30PM +0800, Jun Yao wrote:
>> Create the initial page table in the init_pg_dir. And update the
>> init_mm.pgd to make sure that pgd_offset_k() works correctly. When
>> the final page table is created, we redirect the
Hi Mark,
On 01/10/18 11:41, James Morse wrote:
> On 24/09/18 17:36, Mark Rutland wrote:
>> On Mon, Sep 17, 2018 at 12:43:32PM +0800, Jun Yao wrote:
>>> Since we will move the swapper_pg_dir to rodata section, we need a
>>> way to update it. The fixmap can handle
Hi Mark,
On 01/10/18 11:41, James Morse wrote:
> On 24/09/18 17:36, Mark Rutland wrote:
>> On Mon, Sep 17, 2018 at 12:43:32PM +0800, Jun Yao wrote:
>>> Since we will move the swapper_pg_dir to rodata section, we need a
>>> way to update it. The fixmap can handle
Hi Mark,
On 24/09/18 17:36, Mark Rutland wrote:
> On Mon, Sep 17, 2018 at 12:43:32PM +0800, Jun Yao wrote:
>> Since we will move the swapper_pg_dir to rodata section, we need a
>> way to update it. The fixmap can handle it. When the swapper_pg_dir
>> needs to be updated, we map it dynamically.
Hi Mark,
On 24/09/18 17:36, Mark Rutland wrote:
> On Mon, Sep 17, 2018 at 12:43:32PM +0800, Jun Yao wrote:
>> Since we will move the swapper_pg_dir to rodata section, we need a
>> way to update it. The fixmap can handle it. When the swapper_pg_dir
>> needs to be updated, we map it dynamically.
to swapper_pg_dir
during paging_init()[3].
For the series:
Reviewed-by: James Morse
Thanks,
James
to swapper_pg_dir
during paging_init()[3].
For the series:
Reviewed-by: James Morse
Thanks,
James
Hi Fan,
On 09/04/2018 02:24 PM, Fan Wu wrote:
For platforms whose firmwares provide valid module handles
(SMBIOS type 17) in error records, this patch uses the module
handles to locate corresponding DIMMs and enables per-DIMM
error counter update.
Reviewed-by: James Morse
Thanks,
James
Hi Fan,
On 09/04/2018 02:24 PM, Fan Wu wrote:
For platforms whose firmwares provide valid module handles
(SMBIOS type 17) in error records, this patch uses the module
handles to locate corresponding DIMMs and enables per-DIMM
error counter update.
Reviewed-by: James Morse
Thanks,
James
Hi Daniel, Julien,
On 09/18/2018 12:44 AM, Daniel Thompson wrote:
On Wed, Sep 12, 2018 at 05:49:09PM +0100, Julien Thierry wrote:
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 3bc1c8b..0d1e41e 100644
--- a/arch/arm64/kernel/cpufeature.c
+++
Hi Daniel, Julien,
On 09/18/2018 12:44 AM, Daniel Thompson wrote:
On Wed, Sep 12, 2018 at 05:49:09PM +0100, Julien Thierry wrote:
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 3bc1c8b..0d1e41e 100644
--- a/arch/arm64/kernel/cpufeature.c
+++
Hi Julien,
On 09/12/2018 01:03 PM, Julien Thierry wrote:
On 12/09/18 11:28, James Morse wrote:
On 28/08/18 16:51, Julien Thierry wrote:
The cpu_enable callback for VHE feature requires all alternatives to have
been applied. This prevents applying VHE alternative separately from the
rest.
Use
Hi Julien,
On 09/12/2018 01:03 PM, Julien Thierry wrote:
On 12/09/18 11:28, James Morse wrote:
On 28/08/18 16:51, Julien Thierry wrote:
The cpu_enable callback for VHE feature requires all alternatives to have
been applied. This prevents applying VHE alternative separately from the
rest.
Use
Hi Jun,
On 10/09/18 12:41, Jun Yao wrote:
> On Fri, Sep 07, 2018 at 10:58:22AM +0100, James Morse wrote:
>> On 22/08/18 10:54, Jun Yao wrote:
>>> WRITE_ONCE(*pmdp, pmd);
>>> dsb(ishst);
>>> }
>>> @@ -480,6 +511,19 @@ static inline phys_addr_
Hi Jun,
On 10/09/18 12:41, Jun Yao wrote:
> On Fri, Sep 07, 2018 at 10:58:22AM +0100, James Morse wrote:
>> On 22/08/18 10:54, Jun Yao wrote:
>>> WRITE_ONCE(*pmdp, pmd);
>>> dsb(ishst);
>>> }
>>> @@ -480,6 +511,19 @@ static inline phys_addr_
Hi Jun,
On 13/09/18 11:50, Jun Yao wrote:
> On Fri, Sep 07, 2018 at 10:58:22AM +0100, James Morse wrote:
>> On 22/08/18 10:54, Jun Yao wrote:
>>> WRITE_ONCE(*pmdp, pmd);
>>> dsb(ishst);
>>> }
>>> @@ -480,6 +511,19 @@ static inline phys_addr_
Hi Jun,
On 13/09/18 11:50, Jun Yao wrote:
> On Fri, Sep 07, 2018 at 10:58:22AM +0100, James Morse wrote:
>> On 22/08/18 10:54, Jun Yao wrote:
>>> WRITE_ONCE(*pmdp, pmd);
>>> dsb(ishst);
>>> }
>>> @@ -480,6 +511,19 @@ static inline phys_addr_
Hi Brice,
On 13/09/18 06:51, Brice Goglin wrote:
> Le 12/09/2018 à 11:49, Sudeep Holla a écrit :
>>> Yes. Without this change, we hit the lscpu error in the commit message,
>>> and get zero output about the system. We don't even get information
>>> about the caches which are architecturally
Hi Brice,
On 13/09/18 06:51, Brice Goglin wrote:
> Le 12/09/2018 à 11:49, Sudeep Holla a écrit :
>>> Yes. Without this change, we hit the lscpu error in the commit message,
>>> and get zero output about the system. We don't even get information
>>> about the caches which are architecturally
Hi Julien,
On 12/09/18 12:11, Julien Thierry wrote:
> On 12/09/18 11:32, James Morse wrote:
>> On 28/08/18 16:51, Julien Thierry wrote:
>>> For EL0 entries requiring bp_hardening, daif status is kept at
>>> DAIF_PROCCTX_NOIRQ until after hardening has been done. Then
;msrdaif, %0// local_daif_restore"
> - :
> - : "r" (flags)
> - : "memory");
> +
> + arch_local_irq_restore(flags);
And I thought this only messed with the I bit, which it clearly doesn't.
Thanks for fixing these!
Reviewed-by: James Morse
Hi Julien,
On 12/09/18 12:11, Julien Thierry wrote:
> On 12/09/18 11:32, James Morse wrote:
>> On 28/08/18 16:51, Julien Thierry wrote:
>>> For EL0 entries requiring bp_hardening, daif status is kept at
>>> DAIF_PROCCTX_NOIRQ until after hardening has been done. Then
;msrdaif, %0// local_daif_restore"
> - :
> - : "r" (flags)
> - : "memory");
> +
> + arch_local_irq_restore(flags);
And I thought this only messed with the I bit, which it clearly doesn't.
Thanks for fixing these!
Reviewed-by: James Morse
to that
in the commit message)
Either way,
Acked-by: James Morse
to that
in the commit message)
Either way,
Acked-by: James Morse
Hi Julien,
On 28/08/18 16:51, Julien Thierry wrote:
> Masking daif flags is done very early before returning to EL0.
>
> Only toggle the interrupt masking while in the vector entry and mask daif
> once in kernel_exit.
I had an earlier version that did this, but it showed up as a performance
Hi Julien,
On 28/08/18 16:51, Julien Thierry wrote:
> Masking daif flags is done very early before returning to EL0.
>
> Only toggle the interrupt masking while in the vector entry and mask daif
> once in kernel_exit.
I had an earlier version that did this, but it showed up as a performance
Hi Julien,
On 28/08/18 16:51, Julien Thierry wrote:
> From: Daniel Thompson
>
> Currently alternatives are applied very late in the boot process (and
> a long time after we enable scheduling). Some alternative sequences,
> such as those that alter the way CPU context is stored, must be applied
Hi Julien,
On 28/08/18 16:51, Julien Thierry wrote:
> From: Daniel Thompson
>
> Currently alternatives are applied very late in the boot process (and
> a long time after we enable scheduling). Some alternative sequences,
> such as those that alter the way CPU context is stored, must be applied
Hi Julien,
On 28/08/18 16:51, Julien Thierry wrote:
> The cpu_enable callback for VHE feature requires all alternatives to have
> been applied. This prevents applying VHE alternative separately from the
> rest.
>
> Use an alternative depending on VHE feature to know whether VHE
> alternatives
Hi Julien,
On 28/08/18 16:51, Julien Thierry wrote:
> The cpu_enable callback for VHE feature requires all alternatives to have
> been applied. This prevents applying VHE alternative separately from the
> rest.
>
> Use an alternative depending on VHE feature to know whether VHE
> alternatives
Hi Jun,
On 22/08/18 10:54, Jun Yao wrote:
> Since we will move the swapper_pg_dir to rodata section, we need a
> way to update it. The fixmap can handle it. When the swapper_pg_dir
> needs to be updated, we map it dynamically. The map will be
> canceled after the update is complete. In this way,
Hi Jun,
On 22/08/18 10:54, Jun Yao wrote:
> Since we will move the swapper_pg_dir to rodata section, we need a
> way to update it. The fixmap can handle it. When the swapper_pg_dir
> needs to be updated, we map it dynamically. The map will be
> canceled after the update is complete. In this way,
Hi Jun,
On 22/08/18 10:54, Jun Yao wrote:
> Create the initial page table in the init_pg_dir. And before
> calling kasan_early_init(), we update the init_mm.pgd by
> introducing set_init_mm_pgd(). This will ensure that pgd_offset_k()
> works correctly. When the final page table is created, we
Hi Jun,
On 22/08/18 10:54, Jun Yao wrote:
> Create the initial page table in the init_pg_dir. And before
> calling kasan_early_init(), we update the init_mm.pgd by
> introducing set_init_mm_pgd(). This will ensure that pgd_offset_k()
> works correctly. When the final page table is created, we
Hi Jun,
On 22/08/18 10:54, Jun Yao wrote:
> As the initial page table is created in the init_pg_dir, we can set
> up the final page table directly in the swapper_pg_dir. And it only> contains
> the top level page table, so we can reduce it to a page
Reviewed-by: James Morse
Thanks,
James
Hi Jun,
On 22/08/18 10:54, Jun Yao wrote:
> As the initial page table is created in the init_pg_dir, we can set
> up the final page table directly in the swapper_pg_dir. And it only> contains
> the top level page table, so we can reduce it to a page
Reviewed-by: James Morse
Thanks,
James
/ load TTBR1
> isb
> @@ -791,7 +793,7 @@ ENDPROC(__enable_mmu)
>
> __no_granule_support:
> /* Indicate that this CPU can't boot and is stuck in the kernel */
> - update_early_cpu_boot_status CPU_STUCK_IN_KERNEL, x1, x2
> + update_early_cpu_boot_stat
/ load TTBR1
> isb
> @@ -791,7 +793,7 @@ ENDPROC(__enable_mmu)
>
> __no_granule_support:
> /* Indicate that this CPU can't boot and is stuck in the kernel */
> - update_early_cpu_boot_status CPU_STUCK_IN_KERNEL, x1, x2
> + update_early_cpu_boot_stat
apper_pg_dir during paging_init().
Could you add v3's
| Add init_pg_dir to vmlinux.lds.S and boiler-plate
| clearing/cleaning/invalidating it in head.S.
too. This makes it obvious that 'init_pg_dir isn't used yet' is deliberate.
Reviewed-by: James Morse
Some boring nits:
> diff --git a/arch/ar
Hi Jun,
(I'm a bit confused about which version of this series I should be looking at.
I have a v4, and two v4-resends, all of which are different. Please only mark
something as 'resend' if it is exactly the same!)
On 22/08/18 10:54, Jun Yao wrote:
> The set_init_mm_pgd() is reimplemented using
apper_pg_dir during paging_init().
Could you add v3's
| Add init_pg_dir to vmlinux.lds.S and boiler-plate
| clearing/cleaning/invalidating it in head.S.
too. This makes it obvious that 'init_pg_dir isn't used yet' is deliberate.
Reviewed-by: James Morse
Some boring nits:
> diff --git a/arch/ar
Hi Jun,
(I'm a bit confused about which version of this series I should be looking at.
I have a v4, and two v4-resends, all of which are different. Please only mark
something as 'resend' if it is exactly the same!)
On 22/08/18 10:54, Jun Yao wrote:
> The set_init_mm_pgd() is reimplemented using
Hi Fenghua,
On 27/08/18 15:22, Fenghua Yu wrote:
> On Fri, Aug 24, 2018 at 11:44:59AM +0100, James Morse wrote:
>> ARM have some upcoming CPU features that are similar to Intel RDT. Resctrl
>> is the defacto ABI for this sort of thing, but it lives under arch/x86.
>>
>&g
Hi Fenghua,
On 27/08/18 15:22, Fenghua Yu wrote:
> On Fri, Aug 24, 2018 at 11:44:59AM +0100, James Morse wrote:
>> ARM have some upcoming CPU features that are similar to Intel RDT. Resctrl
>> is the defacto ABI for this sort of thing, but it lives under arch/x86.
>>
>&g
Hi Zhengqiang,
On 29/08/18 19:33, Fan Wu wrote:
> The current ghes_edac driver does not update per-dimm error
> counters when reporting memory errors, because there is no
> platform-independent way to find DIMMs based on the error
> information provided by firmware. This patch offers a solution
>
Hi Zhengqiang,
On 29/08/18 19:33, Fan Wu wrote:
> The current ghes_edac driver does not update per-dimm error
> counters when reporting memory errors, because there is no
> platform-independent way to find DIMMs based on the error
> information provided by firmware. This patch offers a solution
>
301 - 400 of 1082 matches
Mail list logo
