Hi Boris,
On 30/08/18 11:43, Borislav Petkov wrote:
> On Wed, Aug 29, 2018 at 06:33:52PM +, 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
Hi Boris,
On 30/08/18 11:43, Borislav Petkov wrote:
> On Wed, Aug 29, 2018 at 06:33:52PM +, 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
Hi Fan,
On 30/08/18 15:40, wufan wrote:
>>> @@ -327,12 +349,20 @@ void ghes_edac_report_mem_error(int sev,
>> struct cper_sec_mem_err *mem_err)
>>> p += sprintf(p, "bit_pos:%d ", mem_err->bit_pos);
>>> if (mem_err->validation_bits &
>> CPER_MEM_VALID_MODULE_HANDLE) {
>>>
Hi Fan,
On 30/08/18 15:40, wufan wrote:
>>> @@ -327,12 +349,20 @@ void ghes_edac_report_mem_error(int sev,
>> struct cper_sec_mem_err *mem_err)
>>> p += sprintf(p, "bit_pos:%d ", mem_err->bit_pos);
>>> if (mem_err->validation_bits &
>> CPER_MEM_VALID_MODULE_HANDLE) {
>>>
Hi Fan,
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.
I'd argue there is: its in the CPER
Hi Fan,
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.
I'd argue there is: its in the CPER
Hi Boris,
On 29/08/18 08:38, Borislav Petkov wrote:
> On Tue, Aug 28, 2018 at 06:09:24PM +0100, James Morse wrote:
>> Does x86 have another source of memory-topology information it needs to
>> correlate smbios with?
>
> Bah, pinpointing the DIMM on x86 is a mess. There's no
Hi Boris,
On 29/08/18 08:38, Borislav Petkov wrote:
> On Tue, Aug 28, 2018 at 06:09:24PM +0100, James Morse wrote:
>> Does x86 have another source of memory-topology information it needs to
>> correlate smbios with?
>
> Bah, pinpointing the DIMM on x86 is a mess. There's no
Hi Tyler,
On 24/08/18 16:14, Tyler Baicar wrote:
> On Fri, Aug 24, 2018 at 5:48 AM, James Morse wrote:
>> On 23/08/18 16:46, Tyler Baicar wrote:
>>> On Thu, Aug 23, 2018 at 5:29 AM James Morse wrote:
>>>> On 19/07/18 19:36, Tyler Baicar wrote:
>>>>>
Hi Tyler,
On 24/08/18 16:14, Tyler Baicar wrote:
> On Fri, Aug 24, 2018 at 5:48 AM, James Morse wrote:
>> On 23/08/18 16:46, Tyler Baicar wrote:
>>> On Thu, Aug 23, 2018 at 5:29 AM James Morse wrote:
>>>> On 19/07/18 19:36, Tyler Baicar wrote:
>>>>>
Hi Fan,
On 24/08/18 15:30, wufan wrote:
>> Why get avoid the layer stuff? Isn't counting DIMM/memory-devices what
>> EDAC_MC_LAYER_SLOT is for?
>
> Borislav has explained it in his response. Here let me elaborate a little
> more.
> To use the layer information you need an accurate way to
Hi Fan,
On 24/08/18 15:30, wufan wrote:
>> Why get avoid the layer stuff? Isn't counting DIMM/memory-devices what
>> EDAC_MC_LAYER_SLOT is for?
>
> Borislav has explained it in his response. Here let me elaborate a little
> more.
> To use the layer information you need an accurate way to
Hi Boris,
On 24/08/18 13:01, Borislav Petkov wrote:
> On Fri, Aug 24, 2018 at 10:48:24AM +0100, James Morse wrote:
>> so edac_raw_mc_handle_error() has no clue where the error happened. (I
>> haven't
>> read what it does with this information yet).
>
> See edac_
Hi Boris,
On 24/08/18 13:01, Borislav Petkov wrote:
> On Fri, Aug 24, 2018 at 10:48:24AM +0100, James Morse wrote:
>> so edac_raw_mc_handle_error() has no clue where the error happened. (I
>> haven't
>> read what it does with this information yet).
>
> See edac_
this label up to become a property of the schema.
A later patch will correct the closid for CDP when the configuration is
staged, which will let us merge the three types of resource.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 6 ++
arch/x86/kernel/cpu
Now that nothing uses these caches, remove them.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 69 -
arch/x86/kernel/cpu/intel_rdt.h | 4 --
2 files changed, 73 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel_rdt.c b/arch/x86/kernel/cpu
update_domains() applies the staged configuration to the hw_dom's
configuration array and updates the hardware. Make it part of the
interface between resctrl and the arch code.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 4 ++--
include/linux/resctrl.h
, but
eventually resctrl will use the array slots for CODE/DATA/BOTH to
detect a duplicate schema being written.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 44 +++--
include/linux/resctrl.h | 16 ++--
2 files changed, 43 insertions
Now that the cdp_enable() and cdp_disable() calls are basically the same,
merge them into cdp_set_enabled(true/false).
All these functions are behind resctrl_arch_set_cdp_enabled(),
so the can take the rdt_hw_resource directly.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu
Now that the L2/L2CODE/L2DATA resources are merged together, alloc_enabled
doesn't mean anything, its the same as alloc_capable which indicates
CAT is supported by this cache.
Take the opportunity to kill of alloc_enabled and its helpers.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu
this label up to become a property of the schema.
A later patch will correct the closid for CDP when the configuration is
staged, which will let us merge the three types of resource.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 6 ++
arch/x86/kernel/cpu
Now that nothing uses these caches, remove them.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 69 -
arch/x86/kernel/cpu/intel_rdt.h | 4 --
2 files changed, 73 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel_rdt.c b/arch/x86/kernel/cpu
update_domains() applies the staged configuration to the hw_dom's
configuration array and updates the hardware. Make it part of the
interface between resctrl and the arch code.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 4 ++--
include/linux/resctrl.h
, but
eventually resctrl will use the array slots for CODE/DATA/BOTH to
detect a duplicate schema being written.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 44 +++--
include/linux/resctrl.h | 16 ++--
2 files changed, 43 insertions
Now that the cdp_enable() and cdp_disable() calls are basically the same,
merge them into cdp_set_enabled(true/false).
All these functions are behind resctrl_arch_set_cdp_enabled(),
so the can take the rdt_hw_resource directly.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu
Now that the L2/L2CODE/L2DATA resources are merged together, alloc_enabled
doesn't mean anything, its the same as alloc_capable which indicates
CAT is supported by this cache.
Take the opportunity to kill of alloc_enabled and its helpers.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu
the schema is being parsed. In the future this will be the
hardware closid, with the CDP correction already applied by resctrl.
This allows another architecture to work with resctrl, without
having to emulate CDP.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.h | 4
the schema is being parsed. In the future this will be the
hardware closid, with the CDP correction already applied by resctrl.
This allows another architecture to work with resctrl, without
having to emulate CDP.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.h | 4
generating the names
and setting the configuration type.
We can now remove the initialisation of of the illusionary hw_resources:
'cdp_capable' just requires setting a flag, resctrl knows what to do
from there.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 49
code's max_name_width, this is now resctrl's
problem.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 9 ++---
arch/x86/kernel/cpu/intel_rdt.h | 2 +-
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 4 ++--
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
are working with
a per-resource property.
Previously we littered resctrl_to_rdt() wherever we needed to know the
cdp_type of a cache. Now that this has a home, fix all those callers
to read the value from the relevant schema entry.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu
e the same resource represented twice
as code/data, with the appropriate cdp_type for configuration.
This will also let us generate the names in resctrl.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 45 +++-
include/linux/resctrl.h
generating the names
and setting the configuration type.
We can now remove the initialisation of of the illusionary hw_resources:
'cdp_capable' just requires setting a flag, resctrl knows what to do
from there.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 49
code's max_name_width, this is now resctrl's
problem.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 9 ++---
arch/x86/kernel/cpu/intel_rdt.h | 2 +-
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 4 ++--
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
are working with
a per-resource property.
Previously we littered resctrl_to_rdt() wherever we needed to know the
cdp_type of a cache. Now that this has a home, fix all those callers
to read the value from the relevant schema entry.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu
e the same resource represented twice
as code/data, with the appropriate cdp_type for configuration.
This will also let us generate the names in resctrl.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 45 +++-
include/linux/resctrl.h
a resource is reset(), both
the code and data illusionary caches reset the full closid range.
This disappears in a later patch that merges the caches together.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 19 ++-
arch/x86/kernel/cpu/intel_rdt.h
the value it
changed here.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index 58dceaad6863
a resource is reset(), both
the code and data illusionary caches reset the full closid range.
This disappears in a later patch that merges the caches together.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 19 ++-
arch/x86/kernel/cpu/intel_rdt.h
the value it
changed here.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c
index 58dceaad6863
that architectures that don't do this don't need to emulate it.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.h | 4 ++--
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 21 -
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/cpu
that architectures that don't do this don't need to emulate it.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.h | 4 ++--
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 21 -
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/cpu
for each schema. Use the cdp_type enum directly as an index.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 4 ++--
include/linux/resctrl.h | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu
touching a 'hw'
struct indicates where an abstraction is needed.
No change in behaviour, this patch just moves types around.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 87 +++--
arch/x86/kernel/cpu/intel_rdt.h | 30 ---
arch/x86
patch.
No change in behaviour, this patch just moves types around.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 193 +++-
arch/x86/kernel/cpu/intel_rdt.h | 112 +++-
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 6 +-
arch/x86
configuration.
This will allow another architecture to scale the bitmaps if
necessary, and possibly use controls that don't take a bitmap at all.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 17 +
arch/x86/kernel/cpu/intel_rdt_monitor.c | 2 +-
include
-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 1 +
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 72
include/linux/resctrl.h | 7 +++
3 files changed, 57 insertions(+), 23 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel_rdt.c b
.
This series is based on v4.18, and can be retrieved from:
git://linux-arm.org/linux-jm.git -b mpam/resctrl_rework/rfc_1
Thanks,
James Morse (20):
x86/intel_rdt: Split struct rdt_resource
x86/intel_rdt: Split struct rdt_domain
x86/intel_rdt: Group staged configuration into a separate struct
for each schema. Use the cdp_type enum directly as an index.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 4 ++--
include/linux/resctrl.h | 4 +++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/cpu
touching a 'hw'
struct indicates where an abstraction is needed.
No change in behaviour, this patch just moves types around.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 87 +++--
arch/x86/kernel/cpu/intel_rdt.h | 30 ---
arch/x86
patch.
No change in behaviour, this patch just moves types around.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 193 +++-
arch/x86/kernel/cpu/intel_rdt.h | 112 +++-
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 6 +-
arch/x86
configuration.
This will allow another architecture to scale the bitmaps if
necessary, and possibly use controls that don't take a bitmap at all.
Signed-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt_ctrlmondata.c | 17 +
arch/x86/kernel/cpu/intel_rdt_monitor.c | 2 +-
include
-off-by: James Morse
---
arch/x86/kernel/cpu/intel_rdt.c | 1 +
arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 72
include/linux/resctrl.h | 7 +++
3 files changed, 57 insertions(+), 23 deletions(-)
diff --git a/arch/x86/kernel/cpu/intel_rdt.c b
.
This series is based on v4.18, and can be retrieved from:
git://linux-arm.org/linux-jm.git -b mpam/resctrl_rework/rfc_1
Thanks,
James Morse (20):
x86/intel_rdt: Split struct rdt_resource
x86/intel_rdt: Split struct rdt_domain
x86/intel_rdt: Group staged configuration into a separate struct
Now that apply_config() and update_domains() know the code/data/both value
of what they are writing, and ctrl_val is correctly sized: use the
hardware closid slot, based on the configuration type.
This means cbm_idx() and its illusionary cache-properties can go.
Signed-off-by: James Morse
Now that apply_config() and update_domains() know the code/data/both value
of what they are writing, and ctrl_val is correctly sized: use the
hardware closid slot, based on the configuration type.
This means cbm_idx() and its illusionary cache-properties can go.
Signed-off-by: James Morse
Hi Tyler,
On 23/08/18 16:46, Tyler Baicar wrote:
> On Thu, Aug 23, 2018 at 5:29 AM James Morse wrote:
>> On 19/07/18 19:36, Tyler Baicar wrote:
>>> On 7/19/2018 10:46 AM, James Morse wrote:
>>>> On 19/07/18 15:01, Borislav Petkov wrote:
>>>>> On
Hi Tyler,
On 23/08/18 16:46, Tyler Baicar wrote:
> On Thu, Aug 23, 2018 at 5:29 AM James Morse wrote:
>> On 19/07/18 19:36, Tyler Baicar wrote:
>>> On 7/19/2018 10:46 AM, James Morse wrote:
>>>> On 19/07/18 15:01, Borislav Petkov wrote:
>>>>> On
Hi guys,
(CC: +Fan Wu)
On 19/07/18 19:36, Tyler Baicar wrote:
> On 7/19/2018 10:46 AM, James Morse wrote:
>> On 19/07/18 15:01, Borislav Petkov wrote:
>>> On Mon, Jul 16, 2018 at 01:26:49PM -0400, Tyler Baicar wrote:
>>>> Enable per-layer error reporting for
Hi guys,
(CC: +Fan Wu)
On 19/07/18 19:36, Tyler Baicar wrote:
> On 7/19/2018 10:46 AM, James Morse wrote:
>> On 19/07/18 15:01, Borislav Petkov wrote:
>>> On Mon, Jul 16, 2018 at 01:26:49PM -0400, Tyler Baicar wrote:
>>>> Enable per-layer error reporting for
Hi guys,
On 19/07/18 15:01, Borislav Petkov wrote:
> On Mon, Jul 16, 2018 at 01:26:49PM -0400, Tyler Baicar wrote:
>> Enable per-layer error reporting for ARM systems so that the error
>> counters are incremented per-DIMM.
>>
>> On ARM systems that use firmware first error handling it is
Hi guys,
On 19/07/18 15:01, Borislav Petkov wrote:
> On Mon, Jul 16, 2018 at 01:26:49PM -0400, Tyler Baicar wrote:
>> Enable per-layer error reporting for ARM systems so that the error
>> counters are incremented per-DIMM.
>>
>> On ARM systems that use firmware first error handling it is
/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
/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 Yun,
On 02/07/18 12:16, Jun Yao wrote:
> Move {idmap_pg_dir, swapper_pg_dir} to .rodata section and
> populate swapper_pg_dir by fixmap.
(any chance you could split the fixmap bits into a separate patch so that the
rodata move comes last? This will make review and bisecting any problems
Hi Yun,
On 02/07/18 12:16, Jun Yao wrote:
> Move {idmap_pg_dir, swapper_pg_dir} to .rodata section and
> populate swapper_pg_dir by fixmap.
(any chance you could split the fixmap bits into a separate patch so that the
rodata move comes last? This will make review and bisecting any problems
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/proc
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/proc
e 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
e 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
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
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
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/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 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 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 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
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
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
> +++
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
> +++
\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 in here to save duplicating it.
With the link-error fixed:
Reviewed-by:
\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 in here to save duplicating it.
With the link-error fixed:
Reviewed-by:
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
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
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
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
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 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 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
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
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
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
Hi Ard,
On 21/06/18 10:29, Ard Biesheuvel wrote:
> On 21 June 2018 at 10:59, James Morse wrote:
>> On 21/06/18 07:39, Ard Biesheuvel wrote:
>>> On 21 June 2018 at 04:51, Jun Yao wrote:
>>>> On Wed, Jun 20, 2018 at 12:09:49PM +0200, Ard Biesheuvel wrote:
>>&
Hi Ard,
On 21/06/18 10:29, Ard Biesheuvel wrote:
> On 21 June 2018 at 10:59, James Morse wrote:
>> On 21/06/18 07:39, Ard Biesheuvel wrote:
>>> On 21 June 2018 at 04:51, Jun Yao wrote:
>>>> On Wed, Jun 20, 2018 at 12:09:49PM +0200, Ard Biesheuvel wrote:
>>&
Hi guys,
On 21/06/18 07:39, Ard Biesheuvel wrote:
> On 21 June 2018 at 04:51, Jun Yao wrote:
>> On Wed, Jun 20, 2018 at 12:09:49PM +0200, Ard Biesheuvel wrote:
>>> On 20 June 2018 at 10:57, Jun Yao wrote:
Move {idmap_pg_dir,tramp_pg_dir,swapper_pg_dir} to .rodata
section. And update
Hi guys,
On 21/06/18 07:39, Ard Biesheuvel wrote:
> On 21 June 2018 at 04:51, Jun Yao wrote:
>> On Wed, Jun 20, 2018 at 12:09:49PM +0200, Ard Biesheuvel wrote:
>>> On 20 June 2018 at 10:57, Jun Yao wrote:
Move {idmap_pg_dir,tramp_pg_dir,swapper_pg_dir} to .rodata
section. And update
Hi Will, Wei,
On 20/06/18 17:25, Wei Xu wrote:
> On 2018/6/20 23:54, James Morse wrote:
> I have disabled CONFIG_ARM64_RAS_EXTN and reverted that commit.
> But I still got the stack overflow issue sometimes.
> Do you have more hint?
> The log is as below:
> [ 0.000
Hi Will, Wei,
On 20/06/18 17:25, Wei Xu wrote:
> On 2018/6/20 23:54, James Morse wrote:
> I have disabled CONFIG_ARM64_RAS_EXTN and reverted that commit.
> But I still got the stack overflow issue sometimes.
> Do you have more hint?
> The log is as below:
> [ 0.000
Hi Wei,
On 20/06/18 16:52, Wei Xu wrote:
> On 2018/6/20 22:42, Will Deacon wrote:
>> Hmm, I wonder if this is at all related to RAS, since we've just enabled
>> that and if we take a fault whilst rewriting swapper then we're going to
>> get stuck. What happens if you set CONFIG_ARM64_RAS_EXTN=n
Hi Wei,
On 20/06/18 16:52, Wei Xu wrote:
> On 2018/6/20 22:42, Will Deacon wrote:
>> Hmm, I wonder if this is at all related to RAS, since we've just enabled
>> that and if we take a fault whilst rewriting swapper then we're going to
>> get stuck. What happens if you set CONFIG_ARM64_RAS_EXTN=n
401 - 500 of 1082 matches
Mail list logo