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 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 __sdei
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
>
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.
>&
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
PU_CHAR 151
> #define KVM_CAP_S390_BPB 152
> +#define 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 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 migration.
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 a
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 h
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 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 kexe
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(+
ff-by: 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/
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 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 Akashi,
On 09/07/18 01:07, AKASHI Takahiro wrote:
> Patch#2 and #3 addresses kdump case. Ard's patch [4] needs to be applied
> preliminarily.
I missed this, and was then surprised by [0], when I tested kdump.
Could you re-post this with all the dependencies in the series? These changes
need t
if the system table signature is wrong, (or we're out
of memory really early).
I think this is harmless as we end up passing NULL to early_memunmap() which
WARN()s and returns as its outside the fixmap range. Its just more noise on
systems with a corrupt efi system table.
Acked-by: James Morse
Thanks,
James
_TEXT entries.
Signed-off-by: James Morse
---
This will clash with a series from Omar:
https://lkml.org/lkml/2018/7/6/868
fs/proc/kcore.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/proc/kcore.c b/fs/proc/kcore.c
index e64ecb9f2720..66c373230e60 100644
--- a/fs
Hi Jun,
On 25/06/18 12:39, Jun Yao wrote:
> We setup initial page tables in init_pg_dir, which is a reserved
> area of the __initdata section. And in paging_init(), we no
> longer need a temporary top-level and we can setup final page
> tables in swapper_pg_dir directly.
This patch is doing quite
Hi Jun,
On 25/06/18 12:39, Jun Yao wrote:
> When CONFIG_ARM64_VA_BITS_36/CONFIG_ARM64_VA_BITS_39/
> CONFIG_ARM64_VA_BITS_42 are selected, a block-mapping can be
> written to swapper_pg_dir. To defend 'KSMA', we move swapper_pg_dir
> to .rodata section when these configurations are selected. At the
Hi Wei,
On 26/06/18 18:47, Will Deacon wrote:
> On Wed, Jun 27, 2018 at 01:16:44AM +0800, Wei Xu wrote:
>> [0.00] Booting Linux on physical CPU 0x00 [0x480fd010]
>> [0.00] Linux version 4.18.0-rc2-58583-g7daf201-dirty
>
> I'm still suspicious that this is 4.18-rc2
Hi Suzuki, Jun,
On 27/06/18 12:07, Suzuki K Poulose wrote:
> On 25/06/18 12:39, Jun Yao wrote:
>> When CONFIG_ARM64_VA_BITS_36/CONFIG_ARM64_VA_BITS_39/
>> CONFIG_ARM64_VA_BITS_42 are selected, a block-mapping can be
>> written to swapper_pg_dir. To defend 'KSMA', we move swapper_pg_dir
>> to .roda
Hi Wei,
On 27/06/18 14:26, Wei Xu wrote:
> Sorry, I should highlight that I have only updated the default value
> of CONFIG_NR_CPUS by menuconfig in the previous mail.
> That is why it showed dirty.
(menuconfig changes don't show up like this)
More than 64 CPUs ... Is this system running more V
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 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 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 c
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
> --- a/arch/arm6
cro clear_pages, start:req, count:req
> +9997:cbz \count, 9998f
> + clear_page \start
> + sub \count, \count, #1
> + b 9997b
> +9998:
> + .endm
Both callers of this have a start/end address, you may as well move the 'count'
calculation
Hi Jun,
On 02/07/18 12:16, Jun Yao wrote:
> Make __enable_mmu() take the physical address of the ttbr1 page as
> an argument.
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 3f99c59ba193..a1c7a4d3b9f3 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/hea
Hi Jun,
On 02/07/18 12:16, Jun Yao wrote:
> Create initial page tables in init_pg_dir and then create final
> page tables in swapper_pg_dir directly.
This is what the patch does, but doesn't preserve the why for the git-log. Could
you expand it to describe why we're doing this.
The series so fa
Hi Jun,
On 02/07/18 12:16, Jun Yao wrote:
> Make swapper_pg_dir smaller so we don't need to memblock_free() it.
Patch looks good, but could the commit message explain why its now safe to do
this?
Thanks,
James
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
>
Hi Jun,
On 06/07/18 09:58, James Morse wrote:
> The series so far fails to boot from me. This is because the kaslr code tries
> to
> read the kaslr-seed from the DT, via the fixmap. To do this, it needs the
> fixmap
> tables installed, which early_fixmap_init() does.
>
&
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 full
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 better: nm
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 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 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 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 th
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 changes
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 c
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 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
supports RAS without 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
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
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
b/ar
ead_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 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 exten
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 generic
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
>>> compat
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 a/a
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:
https://lists.cs.columbia.edu/piperma
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
st
> 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/ke
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 b
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:
> 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 creating
fore
>>> 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
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 Technology
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 Band
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 Not
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 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
+++ b/arch/arm64/kern
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
O dts /sys/firmware/fdt | grep initrd
| linux,initrd-end = <0x900b6c05 0x8000>;
| linux,initrd-start = <0x906a04 0x8000>;
With the two extra cpu_to_fdt64() calls removed:
Reviewed-by: James Morse
Thanks,
James
Hi Babu,
On 06/04/2021 22:37, Babu Moger wrote:
> On 4/6/21 12:19 PM, James Morse wrote:
>> On 30/03/2021 21:36, Babu Moger wrote:
>>> On 3/12/21 11:58 AM, James Morse wrote:
>>>> This series re-folds the resctrl code so the CDP resources (L3CODE et al)
>>
Hi Reinette,
On 31/03/2021 22:36, Reinette Chatre wrote:
> On 3/12/2021 9:58 AM, James Morse wrote:
>> resctrl is the defacto Linux ABI for SoC resource partitioning features.
>> To support it on another architecture, it needs to be abstracted from
>> the features provided
Hi Reinette,
On 07/04/2021 00:42, Reinette Chatre wrote:
> On 4/6/2021 10:13 AM, James Morse wrote:
>> On 31/03/2021 22:35, Reinette Chatre wrote:
>>> On 3/12/2021 9:58 AM, James Morse wrote:
>>>> resctrl is the defacto Linux ABI for SoC resource partitioning f
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 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 link
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 a PC
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 do
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 b/arch/arm64
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 manner
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 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: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 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' cou
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
> "linux,elfcorehdr",
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, "linux,usable-memory-range"
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 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 Xiongfeng Wang,
On 12/04/2019 13:04, Xiongfeng Wang wrote:
> When I use kprobe to monitor a sdei event handler,
Don't do this! SDEI is like an NMI, it isn't safe to kprobe it as it can
interrupt the
kprobe code, causing it become re-entrant.
> the CPU will hang. It's
> because when I probe
Hi Xiongfeng Wang,
On 12/04/2019 13:04, Xiongfeng Wang wrote:
> When we monitor a sdei_event callback using 'kprobe', the singlestep
> handler can not be called because dbg is masked in sdei_handler.
For a good reason: the debug hardware may be in use single-stepping the kernel,
or worse:
in use
n_id, arg0, arg1, arg2, arg3, arg4, 0, 0, res);
> }
> +NOKPROBE_SYMBOL(sdei_smccc_hvc);
>
> int sdei_register_ghes(struct ghes *ghes, sdei_event_callback *normal_cb,
> sdei_event_callback *critical_cb)
Thanks for making this more robust!
Reviewed-by: James Morse
Thanks,
James
[0]
http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf
Hi guys,
On 05/02/2019 08:38, Borislav Petkov wrote:
> From: Borislav Petkov
>
> Add James to the list of reviewers of the firmware-assisted RAS glue.
Fine by me,
Acked-by: James Morse
Thanks,
James
Hi Boris,
On 23/01/2019 18:46, Borislav Petkov wrote:
> On Wed, Jan 23, 2019 at 06:36:23PM +0000, James Morse wrote:
>>> Would like to know what's the impact if this error happens, and how to fit
>>> it
>>> with current reporting in EDAC core.
>>
Hi Rui,
On 23/01/2019 22:08, Rui Zhao wrote:
> On Wednesday, January 23, 2019 10:36 AM, James Morse wrote:
>>> If firmware enables it, they're suppose to handle the interrupt.
>> Ah, so you still have resident firmware!
>> How come your firmware trusts linux not to t
f necessary when returning to the interrupted context.
Yes please. This would not have been fun to debug!
Reviewed-by: James Morse
I was looking for why we need core code to do this, instead of updating the
arch's call sites. Your 'irqdesc: Add domain handlers for NMIs' patch (poin
Hi Roy,
On 01/04/2019 20:09, Roy Pledge wrote:
> I'm trying to understand if memory reserved in the device tree via the
> "reserved-memory" facility is preserved during a kexec system call,
> i.e., is the memory at the same location with the contents undisturbed
> when the new kernel starts?
If t
Hi Zhang,
On 23/02/2019 13:06, Zhang, Lei wrote:
> Zhang, Lei wrote:
>> I think you mean it may be a problem to modify the KPTI trampoline because
>> some patches about KPTI will be merged to mainline in the near future.
>> I understood that.
>> I should discuss with my colleagues whether we can s
Hi Amit,
On 19/02/2019 09:24, Amit Daniel Kachhap wrote:
> From: Mark Rutland
>
> 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
Hi Amit,
On 25/02/2019 17:39, James Morse wrote:
> On 19/02/2019 09:24, Amit Daniel Kachhap wrote:
>> From: Mark Rutland
>> 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
>>
Hi Amit,
On 19/02/2019 09:24, Amit Daniel Kachhap wrote:
> This patch series adds pointer authentication support for KVM guest and
> is based on top of Linux 5.0-rc6. The basic patches in this series was
> originally posted by Mark Rutland earlier[1,2] and contains some history
> of this work.
>
Hi Amit,
On 19/02/2019 09:24, Amit Daniel Kachhap wrote:
> From: Mark Rutland
>
> 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 a
Hi Amit,
On 19/02/2019 09:24, 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 creating
Hi Amit,
On 19/02/2019 09:24, Amit Daniel Kachhap wrote:
> According to userspace settings, ptrauth key registers are conditionally
> present in guest system register list based on user specified flag
> KVM_ARM_VCPU_PTRAUTH.
>
> Reset routines still sets these registers to default values but they
-off-by: James Morse
Tested-by: zhang.lei
---
(and since posted inline: removed the stray ; on
MIDR_FUJITSU_ERRATUM_010001_MASK)
Changes since [v4]
* Generated MIDR value/mask for __cpu_setup(),
* removed spurious-fault handler,
* always disabled the NFDx bits on affected CPUs
Changes since
Hi Pavel,
On 27/01/2021 17:27, Pavel Tatashin wrote:
> Enable MMU during kexec relocation in order to improve reboot performance.
>
> If kexec functionality is used for a fast system update, with a minimal
> downtime, the relocation of kernel + initramfs takes a significant portion
> of reboot.
>
101 - 200 of 707 matches
Mail list logo
