* Re: [PATCH 4/4] tools/perf: Support pipeline stage cycles for powerpc
From: Athira Rajeev @ 2021-03-15 7:52 UTC (permalink / raw)
To: Jiri Olsa
Cc: Ravi Bangoria, Madhavan Srinivasan, Peter Zijlstra, kjain,
linux-kernel, acme, linux-perf-users, jolsa, linuxppc-dev,
kan.liang
In-Reply-To: <YEtlEyb2z33qHhvO@krava>
> On 12-Mar-2021, at 6:26 PM, Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Tue, Mar 09, 2021 at 09:04:00AM -0500, Athira Rajeev wrote:
>> The pipeline stage cycles details can be recorded on powerpc from
>> the contents of Performance Monitor Unit (PMU) registers. On
>> ISA v3.1 platform, sampling registers exposes the cycles spent in
>> different pipeline stages. Patch adds perf tools support to present
>> two of the cycle counter information along with memory latency (weight).
>>
>> Re-use the field 'ins_lat' for storing the first pipeline stage cycle.
>> This is stored in 'var2_w' field of 'perf_sample_weight'.
>>
>> Add a new field 'p_stage_cyc' to store the second pipeline stage cycle
>> which is stored in 'var3_w' field of perf_sample_weight.
>>
>> Add new sort function 'Pipeline Stage Cycle' and include this in
>> default_mem_sort_order[]. This new sort function may be used to denote
>> some other pipeline stage in another architecture. So add this to
>> list of sort entries that can have dynamic header string.
>>
>> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>> ---
>> tools/perf/Documentation/perf-report.txt | 1 +
>> tools/perf/arch/powerpc/util/event.c | 18 ++++++++++++++++--
>> tools/perf/util/event.h | 1 +
>> tools/perf/util/hist.c | 11 ++++++++---
>> tools/perf/util/hist.h | 1 +
>> tools/perf/util/session.c | 4 +++-
>> tools/perf/util/sort.c | 24 ++++++++++++++++++++++--
>> tools/perf/util/sort.h | 2 ++
>> 8 files changed, 54 insertions(+), 8 deletions(-)
>>
>> diff --git a/tools/perf/Documentation/perf-report.txt b/tools/perf/Documentation/perf-report.txt
>> index f546b5e9db05..9691d9c227ba 100644
>> --- a/tools/perf/Documentation/perf-report.txt
>> +++ b/tools/perf/Documentation/perf-report.txt
>> @@ -112,6 +112,7 @@ OPTIONS
>> - ins_lat: Instruction latency in core cycles. This is the global instruction
>> latency
>> - local_ins_lat: Local instruction latency version
>> + - p_stage_cyc: Number of cycles spent in a pipeline stage.
>
> please specify in here that it's ppc only
Ok Sure,
>
> SNIP
>
>> +struct sort_entry sort_p_stage_cyc = {
>> + .se_header = "Pipeline Stage Cycle",
>> + .se_cmp = sort__global_p_stage_cyc_cmp,
>> + .se_snprintf = hist_entry__p_stage_cyc_snprintf,
>> + .se_width_idx = HISTC_P_STAGE_CYC,
>> +};
>> +
>> struct sort_entry sort_mem_daddr_sym = {
>> .se_header = "Data Symbol",
>> .se_cmp = sort__daddr_cmp,
>> @@ -1853,6 +1872,7 @@ static void sort_dimension_add_dynamic_header(struct sort_dimension *sd)
>> DIM(SORT_CODE_PAGE_SIZE, "code_page_size", sort_code_page_size),
>> DIM(SORT_LOCAL_INS_LAT, "local_ins_lat", sort_local_ins_lat),
>> DIM(SORT_GLOBAL_INS_LAT, "ins_lat", sort_global_ins_lat),
>> + DIM(SORT_P_STAGE_CYC, "p_stage_cyc", sort_p_stage_cyc),
>
> this might be out of scope for this patch, but would it make sense
> to add arch specific sort dimension? so the specific column is
> not even visible on arch that it's not supported on
>
Hi Jiri,
Thanks for the suggestions.
Below is an approach I came up with for adding dynamic sort key based on architecture support.
With this patch, perf report for mem mode will display new sort key only in supported archs.
Please help to review if this approach looks good. I have created this on top of my current set. If this looks fine,
I can include this in version2 patch set.
From 8ebbe6ae802d895103335899e4e60dde5e562f33 Mon Sep 17 00:00:00 2001
From: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Date: Mon, 15 Mar 2021 02:33:28 +0000
Subject: [PATCH] tools/perf: Add dynamic sort dimensions for mem mode
Add dynamic sort dimensions for mem mode.
Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
---
tools/perf/arch/powerpc/util/event.c | 7 +++++
tools/perf/util/event.h | 1 +
tools/perf/util/sort.c | 43 +++++++++++++++++++++++++++-
3 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/tools/perf/arch/powerpc/util/event.c b/tools/perf/arch/powerpc/util/event.c
index b80fbee83b6e..fddfc288c415 100644
--- a/tools/perf/arch/powerpc/util/event.c
+++ b/tools/perf/arch/powerpc/util/event.c
@@ -44,3 +44,10 @@ const char *arch_perf_header_entry__add(const char *se_header)
return "Dispatch Cyc";
return se_header;
}
+
+int arch_support_dynamic_key(const char *sort_key)
+{
+ if (!strcmp(sort_key, "p_stage_cyc"))
+ return 1;
+ return 0;
+}
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 65f89e80916f..6cd4bf54dbdc 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -429,5 +429,6 @@ char *get_page_size_name(u64 size, char *str);
void arch_perf_parse_sample_weight(struct perf_sample *data, const __u64 *array, u64 type);
void arch_perf_synthesize_sample_weight(const struct perf_sample *data, __u64 *array, u64 type);
const char *arch_perf_header_entry__add(const char *se_header);
+int arch_support_dynamic_key(const char *sort_key);
#endif /* __PERF_RECORD_H */
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index cbb3899e7eca..e194b1187db8 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -37,7 +37,7 @@ const char default_parent_pattern[] = "^sys_|^do_page_fault";
const char *parent_pattern = default_parent_pattern;
const char *default_sort_order = "comm,dso,symbol";
const char default_branch_sort_order[] = "comm,dso_from,symbol_from,symbol_to,cycles";
-const char default_mem_sort_order[] = "local_weight,mem,sym,dso,symbol_daddr,dso_daddr,snoop,tlb,locked,blocked,local_ins_lat,p_stage_cyc";
+const char default_mem_sort_order[] = "local_weight,mem,sym,dso,symbol_daddr,dso_daddr,snoop,tlb,locked,blocked,local_ins_lat";
const char default_top_sort_order[] = "dso,symbol";
const char default_diff_sort_order[] = "dso,symbol";
const char default_tracepoint_sort_order[] = "trace";
@@ -47,6 +47,7 @@ regex_t ignore_callees_regex;
int have_ignore_callees = 0;
enum sort_mode sort__mode = SORT_MODE__NORMAL;
const char *dynamic_headers[] = {"local_ins_lat", "p_stage_cyc"};
+const char *dynamic_sort_keys_mem[] = {"p_stage_cyc"};
/*
* Replaces all occurrences of a char used with the:
@@ -2997,6 +2998,20 @@ static char *prefix_if_not_in(const char *pre, char *str)
return n;
}
+/*
+ * Adds 'suff,' suffix into 'str' if 'suff' is
+ * not already part of 'str'.
+ */
+static char *suffix_if_not_in(const char *suff, char *str)
+{
+ if (!str || strstr(str, suff))
+ return str;
+
+ if (asprintf(&str, "%s,%s", str, suff) < 0)
+ str = NULL;
+ return str;
+}
+
static char *setup_overhead(char *keys)
{
if (sort__mode == SORT_MODE__DIFF)
@@ -3010,6 +3025,26 @@ static char *setup_overhead(char *keys)
return keys;
}
+int __weak arch_support_dynamic_key(const char *sort_key __maybe_unused)
+{
+ return 0;
+}
+
+static char *setup_dynamic_sort_keys(char *str)
+{
+ unsigned int j;
+
+ if (sort__mode == SORT_MODE__MEMORY)
+ for (j = 0; j < ARRAY_SIZE(dynamic_sort_keys_mem); j++)
+ if (arch_support_dynamic_key(dynamic_sort_keys_mem[j])) {
+ str = suffix_if_not_in(dynamic_sort_keys_mem[j], str);
+ if (str == NULL)
+ return str;
+ }
+
+ return str;
+}
+
static int __setup_sorting(struct evlist *evlist)
{
char *str;
@@ -3050,6 +3085,12 @@ static int __setup_sorting(struct evlist *evlist)
}
}
+ str = setup_dynamic_sort_keys(str);
+ if (str == NULL) {
+ pr_err("Not enough memory to setup dynamic sort keys");
+ return -ENOMEM;
+ }
+
ret = setup_sort_list(&perf_hpp_list, str, evlist);
free(str);
--
2.26.2
Thanks,
Athira
>
>> };
>>
>> #undef DIM
>> diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
>> index 63f67a3f3630..23b20cbbc846 100644
>> --- a/tools/perf/util/sort.h
>> +++ b/tools/perf/util/sort.h
>> @@ -51,6 +51,7 @@ struct he_stat {
>> u64 period_guest_us;
>> u64 weight;
>> u64 ins_lat;
>> + u64 p_stage_cyc;
>> u32 nr_events;
>> };
>>
>> @@ -234,6 +235,7 @@ enum sort_type {
>> SORT_CODE_PAGE_SIZE,
>> SORT_LOCAL_INS_LAT,
>> SORT_GLOBAL_INS_LAT,
>> + SORT_P_STAGE_CYC,
>
> we could have the whole 'SORT_PEPELINE_STAGE_CYC',
> so it's more obvious
Ok.
>
> thanks,
> jirka
^ permalink raw reply related
* Re: [PATCH 15/17] iommu: remove DOMAIN_ATTR_NESTING
From: Auger Eric @ 2021-03-15 7:52 UTC (permalink / raw)
To: Christoph Hellwig
Cc: kvm, Will Deacon, Joerg Roedel, linuxppc-dev, dri-devel, Li Yang,
iommu, netdev, linux-arm-kernel, virtualization, freedreno,
David Woodhouse, linux-arm-msm
In-Reply-To: <20210314155813.GA788@lst.de>
Hi Christoph,
On 3/14/21 4:58 PM, Christoph Hellwig wrote:
> On Sun, Mar 14, 2021 at 11:44:52AM +0100, Auger Eric wrote:
>> As mentionned by Robin, there are series planning to use
>> DOMAIN_ATTR_NESTING to get info about the nested caps of the iommu (ARM
>> and Intel):
>>
>> [Patch v8 00/10] vfio: expose virtual Shared Virtual Addressing to VMs
>> patches 1, 2, 3
>>
>> Is the plan to introduce a new domain_get_nesting_info ops then?
>
> The plan as usual would be to add it the series adding that support.
> Not sure what the merge plans are - if the series is ready to be
> merged I could rebase on top of it, otherwise that series will need
> to add the method.
OK I think your series may be upstreamed first.
Thanks
Eric
>
^ permalink raw reply
* Re: VIO bus not initialized
From: Michael Ellerman @ 2021-03-15 7:53 UTC (permalink / raw)
To: Paul Menzel, Benjamin Herrenschmidt, Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <41c04182-20c1-6124-a221-90aef704e310@molgen.mpg.de>
Paul Menzel <pmenzel@molgen.mpg.de> writes:
> Dear Linux folks,
>
>
> On the POWER8 system IBM S822LC, Linux 5.12-rc2+ logs the errors below.
That's a bare metal system, you can see that from the line "Using
PowerNV machine description" in the boot log.
> $ dmesg --level=err
> [ 1.555668] Driver 'hvc_console' was unable to register with
> bus_type 'vio' because the bus was not initialized.
> [ 1.558434] Driver 'tpm_ibmvtpm' was unable to register with
> bus_type 'vio' because the bus was not initialized.
> $ grep VIO /boot/config-5.12.0-rc2+
> CONFIG_IBMVIO=y
The "vio" bus is not a real bus, it's a fake bus we use for hypervisor
provided devices in LPARs (guests).
So on bare metal machines there is no vio bus, the devices that would
appear on the vio bus are found via other mechanisms.
> [ 1.555668] Driver 'hvc_console' was unable to register with bus_type 'vio' because the bus was not initialized.
> [ 1.555866] hvc0: raw protocol on /ibm,opal/consoles/serial@0 (boot console)
> [ 1.555875] hvc0: No interrupts property, using OPAL event
You can see here that the hvc opal driver found the console, which is
the bare metal equivalent of the hvc console (vio) driver.
> [ 1.556205] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
> [ 1.558377] Non-volatile memory driver v1.3
> [ 1.558404] Linux agpgart interface v0.103
> [ 1.558434] Driver 'tpm_ibmvtpm' was unable to register with bus_type 'vio' because the bus was not initialized.
The ibmvtpm driver is a Virtual TPM driver, so it also isn't present on
a bare metal system.
I don't think that system has a TPM, but if it did you'd need the
appropriate bare metal TPM driver to use it.
cheers
^ permalink raw reply
* [PATCH 1/2] powerpc/pseries/mobility: use struct for shared state
From: Nathan Lynch @ 2021-03-15 8:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tyreld, brking, npiggin
In-Reply-To: <20210315080045.460331-1-nathanl@linux.ibm.com>
The atomic_t counter is the only shared state for the join/suspend
sequence so far, but that will change. Contain it in a
struct (pseries_suspend_info), and document its intended use. No
functional change.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
arch/powerpc/platforms/pseries/mobility.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
index ea4d6a660e0d..a6739ce9feac 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -452,9 +452,21 @@ static int do_suspend(void)
return ret;
}
+/**
+ * struct pseries_suspend_info - State shared between CPUs for join/suspend.
+ * @counter: Threads are to increment this upon resuming from suspend
+ * or if an error is received from H_JOIN. The thread which performs
+ * the first increment (i.e. sets it to 1) is responsible for
+ * waking the other threads.
+ */
+struct pseries_suspend_info {
+ atomic_t counter;
+};
+
static int do_join(void *arg)
{
- atomic_t *counter = arg;
+ struct pseries_suspend_info *info = arg;
+ atomic_t *counter = &info->counter;
long hvrc;
int ret;
@@ -535,11 +547,15 @@ static int pseries_suspend(u64 handle)
int ret;
while (true) {
- atomic_t counter = ATOMIC_INIT(0);
+ struct pseries_suspend_info info;
unsigned long vasi_state;
int vasi_err;
- ret = stop_machine(do_join, &counter, cpu_online_mask);
+ info = (struct pseries_suspend_info) {
+ .counter = ATOMIC_INIT(0),
+ };
+
+ ret = stop_machine(do_join, &info, cpu_online_mask);
if (ret == 0)
break;
/*
--
2.29.2
^ permalink raw reply related
* [PATCH 0/2] handle premature return from H_JOIN in pseries mobility code
From: Nathan Lynch @ 2021-03-15 8:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tyreld, brking, npiggin
pseries VMs in shared processor mode are susceptible to failed
migrations becasue stray H_PRODs from the paravirt spinlock
implementation can bump threads out of joining state before the
suspend has occurred. Fix this by adding a small amount of shared
state and ordering accesses to it with respect to H_PROD and H_JOIN.
Nathan Lynch (2):
powerpc/pseries/mobility: use struct for shared state
powerpc/pseries/mobility: handle premature return from H_JOIN
arch/powerpc/platforms/pseries/mobility.c | 48 +++++++++++++++++++++--
1 file changed, 44 insertions(+), 4 deletions(-)
--
2.29.2
^ permalink raw reply
* [PATCH 2/2] powerpc/pseries/mobility: handle premature return from H_JOIN
From: Nathan Lynch @ 2021-03-15 8:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tyreld, brking, npiggin
In-Reply-To: <20210315080045.460331-1-nathanl@linux.ibm.com>
The pseries join/suspend sequence in its current form was written with
the assumption that it was the only user of H_PROD and that it needn't
handle spurious successful returns from H_JOIN. That's wrong;
powerpc's paravirt spinlock code uses H_PROD, and CPUs entering
do_join() can be woken prematurely from H_JOIN with a status of
H_SUCCESS as a result. This causes all CPUs to exit the sequence
early, preventing suspend from occurring at all.
Add a 'done' boolean flag to the pseries_suspend_info struct, and have
the waking thread set it before waking the other threads. Threads
which receive H_SUCCESS from H_JOIN retry if the 'done' flag is still
unset.
Fixes: 9327dc0aeef3 ("powerpc/pseries/mobility: use stop_machine for join/suspend")
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
arch/powerpc/platforms/pseries/mobility.c | 26 ++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/mobility.c b/arch/powerpc/platforms/pseries/mobility.c
index a6739ce9feac..e83e0891272d 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -458,9 +458,12 @@ static int do_suspend(void)
* or if an error is received from H_JOIN. The thread which performs
* the first increment (i.e. sets it to 1) is responsible for
* waking the other threads.
+ * @done: False if join/suspend is in progress. True if the operation is
+ * complete (successful or not).
*/
struct pseries_suspend_info {
atomic_t counter;
+ bool done;
};
static int do_join(void *arg)
@@ -470,6 +473,7 @@ static int do_join(void *arg)
long hvrc;
int ret;
+retry:
/* Must ensure MSR.EE off for H_JOIN. */
hard_irq_disable();
hvrc = plpar_hcall_norets(H_JOIN);
@@ -485,8 +489,20 @@ static int do_join(void *arg)
case H_SUCCESS:
/*
* The suspend is complete and this cpu has received a
- * prod.
+ * prod, or we've received a stray prod from unrelated
+ * code (e.g. paravirt spinlocks) and we need to join
+ * again.
+ *
+ * This barrier orders the return from H_JOIN above vs
+ * the load of info->done. It pairs with the barrier
+ * in the wakeup/prod path below.
*/
+ smp_mb();
+ if (READ_ONCE(info->done) == false) {
+ pr_info_ratelimited("premature return from H_JOIN on CPU %i, retrying",
+ smp_processor_id());
+ goto retry;
+ }
ret = 0;
break;
case H_BAD_MODE:
@@ -500,6 +516,13 @@ static int do_join(void *arg)
if (atomic_inc_return(counter) == 1) {
pr_info("CPU %u waking all threads\n", smp_processor_id());
+ WRITE_ONCE(info->done, true);
+ /*
+ * This barrier orders the store to info->done vs subsequent
+ * H_PRODs to wake the other CPUs. It pairs with the barrier
+ * in the H_SUCCESS case above.
+ */
+ smp_mb();
prod_others();
}
/*
@@ -553,6 +576,7 @@ static int pseries_suspend(u64 handle)
info = (struct pseries_suspend_info) {
.counter = ATOMIC_INIT(0),
+ .done = false,
};
ret = stop_machine(do_join, &info, cpu_online_mask);
--
2.29.2
^ permalink raw reply related
* Re: VIO bus not initialized
From: Paul Menzel @ 2021-03-15 8:11 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <87mtv44zut.fsf@mpe.ellerman.id.au>
Dear Michael,
Thank you very much for your response.
Am 15.03.21 um 08:53 schrieb Michael Ellerman:
> Paul Menzel writes:
>> On the POWER8 system IBM S822LC, Linux 5.12-rc2+ logs the errors below.
>
> That's a bare metal system, you can see that from the line "Using
> PowerNV machine description" in the boot log.
>
>> $ dmesg --level=err
>> [ 1.555668] Driver 'hvc_console' was unable to register with bus_type 'vio' because the bus was not initialized.
>> [ 1.558434] Driver 'tpm_ibmvtpm' was unable to register with bus_type 'vio' because the bus was not initialized.
>> $ grep VIO /boot/config-5.12.0-rc2+
>> CONFIG_IBMVIO=y
>
> The "vio" bus is not a real bus, it's a fake bus we use for hypervisor
> provided devices in LPARs (guests).
>
> So on bare metal machines there is no vio bus, the devices that would
> appear on the vio bus are found via other mechanisms.
Thank you for the explanation. Two questions:
1. Could a bare metal system be detected, and the VIO “be skipped”?
2. Should the log level be changed to notice or info then, as it’s an
expected failure?
[…]
Kind regards,
Paul
^ permalink raw reply
* Re: [PATCH 10/10] powerpc: move norestart trap flag to bit 0
From: Christophe Leroy @ 2021-03-15 8:14 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Scott Wood
In-Reply-To: <20210315031716.3940350-11-npiggin@gmail.com>
Le 15/03/2021 à 04:17, Nicholas Piggin a écrit :
> Compact the trap flags down to use the low 4 bits of regs.trap.
>
> A few 64e interrupt trap numbers set bit 4. Although they tended to be
> trivial so it wasn't a real problem[1], it is not the right thing to do,
> and confusing.
>
> [*] E.g., 0x310 hypercall goes to unknown_exception, which prints
> regs->trap directly so 0x310 will appear fine, and only the syscall
> interrupt will test norestart, so it won't be confused by 0x310.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/include/asm/ptrace.h | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
> index 91194fdd5d01..6a04abfe5eb6 100644
> --- a/arch/powerpc/include/asm/ptrace.h
> +++ b/arch/powerpc/include/asm/ptrace.h
> @@ -185,15 +185,21 @@ static inline void regs_set_return_value(struct pt_regs *regs, unsigned long rc)
> #define current_pt_regs() \
> ((struct pt_regs *)((unsigned long)task_stack_page(current) + THREAD_SIZE) - 1)
>
> +/*
> + * The 4 low bits (0xf) are available as flags to overload the trap word,
> + * because interrupt vectors have minimum alignment of 0x10. TRAP_FLAGS_MASK
> + * must cover the bits used as flags, including bit 0 which is used as the
> + * "norestart" bit.
> + */
> #ifdef __powerpc64__
> -#define TRAP_FLAGS_MASK 0x10
> +#define TRAP_FLAGS_MASK 0x1
> #define TRAP(regs) ((regs)->trap & ~TRAP_FLAGS_MASK)
> #else
> /*
> * On 4xx we use bit 1 in the trap word to indicate whether the exception
> * is a critical exception (1 means it is).
> */
> -#define TRAP_FLAGS_MASK 0x1E
> +#define TRAP_FLAGS_MASK 0xf
Could we set 0xf for all and remove the ifdef __powerpc64__ ?
> #define TRAP(regs) ((regs)->trap & ~TRAP_FLAGS_MASK)
> #define IS_CRITICAL_EXC(regs) (((regs)->trap & 2) != 0)
> #define IS_MCHECK_EXC(regs) (((regs)->trap & 4) != 0)
> @@ -222,12 +228,12 @@ static inline bool trap_is_syscall(struct pt_regs *regs)
>
> static inline bool trap_norestart(struct pt_regs *regs)
> {
> - return regs->trap & 0x10;
> + return regs->trap & 0x1;
> }
>
> static inline void set_trap_norestart(struct pt_regs *regs)
> {
> - regs->trap |= 0x10;
> + regs->trap |= 0x1;
> }
>
> #define arch_has_single_step() (1)
>
While we are playing with ->trap, in mm/book3s64/hash_utils.c there is an if (regs->trap == 0x400).
Should be TRAP(regs) == 0x400 ?
Christophe
^ permalink raw reply
* Re: [PATCH 03/10] powerpc/64e/interrupt: use new interrupt return
From: Christophe Leroy @ 2021-03-15 8:20 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Scott Wood
In-Reply-To: <186d3513-d7ab-a658-cdb2-6fe5146c1fc4@csgroup.eu>
Le 15/03/2021 à 08:50, Christophe Leroy a écrit :
>
>
> Le 15/03/2021 à 04:17, Nicholas Piggin a écrit :
>> Update the new C and asm interrupt return code to account for 64e
>> specifics, switch over to use it.
>>
>> The now-unused old ret_from_except code, that was moved to 64e after the
>> 64s conversion, is removed.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/include/asm/asm-prototypes.h | 2 -
>> arch/powerpc/kernel/entry_64.S | 9 +-
>> arch/powerpc/kernel/exceptions-64e.S | 321 ++--------------------
>> arch/powerpc/kernel/interrupt.c | 27 +-
>> arch/powerpc/kernel/irq.c | 76 -----
>> 5 files changed, 56 insertions(+), 379 deletions(-)
>>
>> @@ -1016,284 +1021,8 @@ alignment_more:
>
> ...
>
>> -fast_exception_return:
>> - wrteei 0
>> -1: mr r0,r13
>> - ld r10,_MSR(r1)
>> - REST_4GPRS(2, r1)
>> - andi. r6,r10,MSR_PR
>> - REST_2GPRS(6, r1)
>> - beq 1f
>> - ACCOUNT_CPU_USER_EXIT(r13, r10, r11)
>
> Then ACCOUNT_CPU_USER_EXIT can be removed from asm/ppc_asm.h
>
And all associated definitions in asm-offsets.c
And also ACCOUNT_USER_TIME which was likely left over after the removal of ACCOUNT_CPU_USER_ENTRY()
^ permalink raw reply
* Re: [PATCH 14/17] iommu: remove DOMAIN_ATTR_DMA_USE_FLUSH_QUEUE
From: Christoph Hellwig @ 2021-03-15 8:33 UTC (permalink / raw)
To: Robin Murphy
Cc: kvm, Will Deacon, Joerg Roedel, linuxppc-dev, dri-devel, Li Yang,
iommu, netdev, David Woodhouse, linux-arm-kernel, virtualization,
freedreno, Christoph Hellwig, linux-arm-msm
In-Reply-To: <dff8eb80-8f74-972b-17e9-496c1fc0396f@arm.com>
On Fri, Mar 12, 2021 at 04:18:24PM +0000, Robin Murphy wrote:
>> Let me know what you think of the version here:
>>
>> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/iommu-cleanup
>>
>> I'll happily switch the patch to you as the author if you're fine with
>> that as well.
>
> I still have reservations about removing the attribute API entirely and
> pretending that io_pgtable_cfg is anything other than a SoC-specific
> private interface,
I think a private inteface would make more sense. For now I've just
condensed it down to a generic set of quirk bits and dropped the
attrs structure, which seems like an ok middle ground for now. That
being said I wonder why that quirk isn't simply set in the device
tree?
> but the reworked patch on its own looks reasonable to
> me, thanks! (I wasn't too convinced about the iommu_cmd_line wrappers
> either...) Just iommu_get_dma_strict() needs an export since the SMMU
> drivers can be modular - I consciously didn't add that myself since I was
> mistakenly thinking only iommu-dma would call it.
Fixed. Can I get your signoff for the patch? Then I'll switch it to
over to being attributed to you.
^ permalink raw reply
* Re: [PATCH] powerpc/asm: Remove unused symbols in asm-offsets.c
From: Christophe Leroy @ 2021-03-15 8:35 UTC (permalink / raw)
To: Rashmica Gupta, linuxppc-dev, mpe, benh, paulus
In-Reply-To: <1464821807-3154-1-git-send-email-rashmicy@gmail.com>
Le 02/06/2016 à 00:56, Rashmica Gupta a écrit :
> ---
> GPR15, GPR16, GPR17, GPR18, GPR19, GPR20, GPR21, GPR22, GPR23, GPR24,
> GPR25, GPR26, GPR27, GPR28, GPR29 and GPR30: Added in commit
> a4bcbe6a41ad ("powerpc: Remove old compile time disabled syscall tracing
> code") and were never used.
> ---
GPR14 has never been used either. You only find it in a couple of comments.
^ permalink raw reply
* RE: [PATCH] powerpc/603: Fix protection of user pages mapped with PROT_NONE
From: PLATTNER Christoph @ 2021-03-15 8:55 UTC (permalink / raw)
To: Michael Ellerman, Michael Ellerman, Paul Mackerras,
Benjamin Herrenschmidt, Christophe Leroy
Cc: PLATTNER Christoph, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org
In-Reply-To: <161571587047.138988.3119931595106306211.b4-ty@ellerman.id.au>
Thank you for maintenance and for following this request.
Regards
Christoph
-----Original Message-----
From: Michael Ellerman <patch-notifications@ellerman.id.au>
Sent: Sonntag, 14. März 2021 11:01
To: Michael Ellerman <mpe@ellerman.id.au>; Paul Mackerras <paulus@samba.org>; Benjamin Herrenschmidt <benh@kernel.crashing.org>; PLATTNER Christoph <christoph.plattner@thalesgroup.com>; Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: linux-kernel@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/603: Fix protection of user pages mapped with PROT_NONE
On Mon, 1 Feb 2021 06:29:50 +0000 (UTC), Christophe Leroy wrote:
> On book3s/32, page protection is defined by the PP bits in the PTE
> which provide the following protection depending on the access keys
> defined in the matching segment register:
> - PP 00 means RW with key 0 and N/A with key 1.
> - PP 01 means RW with key 0 and RO with key 1.
> - PP 10 means RW with both key 0 and key 1.
> - PP 11 means RO with both key 0 and key 1.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/603: Fix protection of user pages mapped with PROT_NONE
https://git.kernel.org/powerpc/c/c119565a15a628efdfa51352f9f6c5186e506a1c
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: define the variable 'uaccess_flush' as static
From: heying (H) @ 2021-03-15 6:51 UTC (permalink / raw)
To: Cédric Le Goater, mpe, benh, paulus, npiggin, dja, akpm,
rppt, aneesh.kumar
Cc: johnny.chenyi, linuxppc-dev, linux-kernel
In-Reply-To: <a06a0dc8-c717-da4c-c5ad-eaf56bbbd896@kaod.org>
[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]
> I think this is the case also for entry_flush. compiling with W=1 will tell you more.
When I use these commands:
make allmodconfig ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu-
make C=2 arch/powerpc/kernel/setup_64.o ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu-
I find warnings as followings:
arch/powerpc/kernel/setup_64.c:422:6: warning: symbol
'panic_smp_self_stop' was not declared. Should it be static?
arch/powerpc/kernel/setup_64.c:951:6: warning: symbol 'rfi_flush' was
not declared. Should it be static?
arch/powerpc/kernel/setup_64.c:952:6: warning: symbol 'entry_flush' was
not declared. Should it be static?
arch/powerpc/kernel/setup_64.c:953:6: warning: symbol 'uaccess_flush'
was not declared. Should it be static?
When I use the command "make W=1 arch/powerpc/kernel/setup_64.o
ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu-", warning becomes this:
arch/powerpc/kernel/setup_64.c:422:6: warning: no previous prototype for
‘panic_smp_self_stop’ [-Wmissing-prototypes]
void panic_smp_self_stop(void)
^~~~~~~~~~~~~~~~~~~
My sparse tool is the latest one with the version "v0.6.3". So, should I
fix all the warnings reported by sparse?
Thanks.
[-- Attachment #2: Type: text/html, Size: 2430 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: define the variable 'uaccess_flush' as static
From: Christophe Leroy @ 2021-03-15 9:16 UTC (permalink / raw)
To: heying (H), Cédric Le Goater, mpe, benh, paulus, npiggin,
dja, akpm, rppt, aneesh.kumar
Cc: johnny.chenyi, linuxppc-dev, linux-kernel
In-Reply-To: <2c7bf6e0-d950-c728-bfe9-2db99a4d18a9@huawei.com>
Le 15/03/2021 à 07:51, heying (H) a écrit :
>
>> I think this is the case also for entry_flush. compiling with W=1 will tell you more.
>
> When I use these commands:
>
> make allmodconfig ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu-
> make C=2 arch/powerpc/kernel/setup_64.o ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu-
>
> I find warnings as followings:
>
> arch/powerpc/kernel/setup_64.c:422:6: warning: symbol 'panic_smp_self_stop' was not declared. Should
> it be static?
> arch/powerpc/kernel/setup_64.c:951:6: warning: symbol 'rfi_flush' was not declared. Should it be static?
> arch/powerpc/kernel/setup_64.c:952:6: warning: symbol 'entry_flush' was not declared. Should it be
> static?
> arch/powerpc/kernel/setup_64.c:953:6: warning: symbol 'uaccess_flush' was not declared. Should it be
> static?
>
> When I use the command "make W=1 arch/powerpc/kernel/setup_64.o ARCH=powerpc
> CROSS_COMPILE=powerpc64-linux-gnu-", warning becomes this:
>
> arch/powerpc/kernel/setup_64.c:422:6: warning: no previous prototype for ‘panic_smp_self_stop’
> [-Wmissing-prototypes]
> void panic_smp_self_stop(void)
> ^~~~~~~~~~~~~~~~~~~
>
> My sparse tool is the latest one with the version "v0.6.3". So, should I fix all the warnings
> reported by sparse?
I think W=1 will only report missing function prototypes.
sparse also reports missing variables prototypes so that's better. All should be fixed.
Christophe
^ permalink raw reply
* Re: [PATCH] powerpc: define the variable 'uaccess_flush' as static
From: heying (H) @ 2021-03-15 9:32 UTC (permalink / raw)
To: Christophe Leroy, Cédric Le Goater, mpe, benh, paulus,
npiggin, dja, akpm, rppt, aneesh.kumar
Cc: johnny.chenyi, linuxppc-dev
In-Reply-To: <c522ca02-4053-3e3d-f25e-2c1482c5a8bd@csgroup.eu>
Hello,
在 2021/3/15 17:16, Christophe Leroy 写道:
>
>
> I think W=1 will only report missing function prototypes.
>
> sparse also reports missing variables prototypes so that's better. All
> should be fixed.
>
OK. I'll try to fix all the warnings in the file
"arch/powerpc/kernel/setup_64.c" reported by sparse and send the patch
V2 soon.
Thanks.
^ permalink raw reply
* RE: Errant readings on LM81 with T2080 SoC
From: David Laight @ 2021-03-15 9:46 UTC (permalink / raw)
To: 'Chris Packham', 'Guenter Roeck', Wolfram Sang
Cc: linux-hwmon@vger.kernel.org, jdelvare@suse.com,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-i2c@vger.kernel.org
In-Reply-To: <ec89dfda-a321-6ec7-9da0-b4949f1f28b5@alliedtelesis.co.nz>
From: Chris Packham
> Sent: 14 March 2021 21:26
>
> On 12/03/21 10:25 pm, David Laight wrote:
> > From: Linuxppc-dev Guenter Roeck
> >> Sent: 11 March 2021 21:35
> >>
> >> On 3/11/21 1:17 PM, Chris Packham wrote:
> >>> On 11/03/21 9:18 pm, Wolfram Sang wrote:
> >>>>> Bummer. What is really weird is that you see clock stretching under
> >>>>> CPU load. Normally clock stretching is triggered by the device, not
> >>>>> by the host.
> >>>> One example: Some hosts need an interrupt per byte to know if they
> >>>> should send ACK or NACK. If that interrupt is delayed, they stretch the
> >>>> clock.
> >>>>
> >>> It feels like something like that is happening. Looking at the T2080
> >>> Reference manual there is an interesting timing diagram (Figure 14-2 if
> >>> someone feels like looking it up). It shows SCL low between the ACK for
> >>> the address and the data byte. I think if we're delayed in sending the
> >>> next byte we could violate Ttimeout or Tlow:mext from the SMBUS spec.
> >>>
> >> I think that really leaves you only two options that I can see:
> >> Rework the driver to handle critical actions (such as setting TXAK,
> >> and everything else that might result in clock stretching) in the
> >> interrupt handler, or rework the driver to handle everything in
> >> a high priority kernel thread.
> >
> > I'm not sure a high priority kernel thread will help.
> > Without CONFIG_PREEMPT (which has its own set of nasties)
> > a RT process won't be scheduled until the processor it last
> > ran on does a reschedule.
> > I don't think a kernel thread will be any different from a
> > user process running under the RT scheduler.
> >
> > I'm trying to remember the smbus spec (without remembering the I2C one).
> For those following along the spec is available here[0]. I know there's
> a 3.0 version[1] as well but the devices I'm dealing with are from a 2.0
> vintage.
> > While basically a clock+data bit-bang the slave is allowed to drive
> > the clock low to extend a cycle.
> > It may be allowed to do this at any point?
>
> From what I can see it's actually the master extending the clock. Or
> more accurately holding it low between the address and data bytes (which
> from the T2080 reference manual looks expected). I think this may cause
> a strictly compliant SMBUS device to determine that Tlow:mext has been
> violated.
Yes, the spec does seem to assume that is a signal is stable
for 20ms something has gone 'horribly wrong'.
I wasn't worries about that, our fpga does the whole transaction
as a single command.
None of our slaves generate interrupts - so it is purely master/slave.
If you run your process under the RT scheduler it is unlikely
that pre-emption will be delayed by long enough to stop the process
running for 10ms.
I've seen >1ms delays (testing RTP audio), but most of the long
loops have a cond_resched() in them.
...
> Probably depends on the device implementation. I've got multiple other
> I2C/SMBUS devices and the LM81 seems to be the one that objects.
I bet most don't implement any of the timeouts.
I found one interesting pmbus device.
Sometimes it would detect a STOP condition because the data line
went high when it tri-stated its output driver in response to the
rising clock edge!
So it saw the same clock edge twice.
> [0] - http://www.smbus.org/specs/smbus20.pdf
> [1] - https://pmbus.org/Assets/PDFS/Public/SMBus_3_0_20141220.pdf
I should have both those - I've copied them to the directory where
I'd look for them first!
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: Build regressions/improvements in v5.12-rc3
From: Geert Uytterhoeven @ 2021-03-15 10:49 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: linuxppc-dev
In-Reply-To: <20210315104409.1598822-1-geert@linux-m68k.org>
On Mon, Mar 15, 2021 at 11:46 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> JFYI, when comparing v5.12-rc3[1] to v5.12-rc2[3], the summaries are:
> - build errors: +2/-2
> 2 error regressions:
> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_248' declared with attribute error: BUILD_BUG failed: => 320:38
> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_249' declared with attribute error: BUILD_BUG failed: => 320:38
powerpc-gcc4.9/ppc64_book3e_allmodconfig
So we traded implicit declaration errors:
- /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:
error: implicit declaration of function 'disable_kernel_vsx'
[-Werror=implicit-function-declaration]: 674:2 =>
- /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:
error: implicit declaration of function 'enable_kernel_vsx'
[-Werror=implicit-function-declaration]: 638:2 =>
for compile-time assertions.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Build regressions/improvements in v5.12-rc3
From: Christophe Leroy @ 2021-03-15 10:54 UTC (permalink / raw)
To: Geert Uytterhoeven, Linux Kernel Mailing List; +Cc: linuxppc-dev
In-Reply-To: <CAMuHMdVJFprsj9njwv13jWTBELuq8RcXOmR7AoR9dqDdydLcNQ@mail.gmail.com>
Le 15/03/2021 à 11:49, Geert Uytterhoeven a écrit :
> On Mon, Mar 15, 2021 at 11:46 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
>> JFYI, when comparing v5.12-rc3[1] to v5.12-rc2[3], the summaries are:
>> - build errors: +2/-2
>
>> 2 error regressions:
>> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_248' declared with attribute error: BUILD_BUG failed: => 320:38
>> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_249' declared with attribute error: BUILD_BUG failed: => 320:38
>
> powerpc-gcc4.9/ppc64_book3e_allmodconfig
>
> So we traded implicit declaration errors:
>
> - /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:
> error: implicit declaration of function 'disable_kernel_vsx'
> [-Werror=implicit-function-declaration]: 674:2 =>
> - /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:
> error: implicit declaration of function 'enable_kernel_vsx'
> [-Werror=implicit-function-declaration]: 638:2 =>
>
> for compile-time assertions.
>
You are missing https://github.com/linuxppc/linux/commit/eed5fae00593ab9d261a0c1ffc1bdb786a87a55a
Christophe
^ permalink raw reply
* [PATCH] powerpc/asm-offsets: GPR14 is not needed either
From: Christophe Leroy @ 2021-03-15 11:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
rashmicy
Cc: linuxppc-dev, linux-kernel
Commit aac6a91fea93 ("powerpc/asm: Remove unused symbols in
asm-offsets.c") removed GPR15 to GPR31 but kept GPR14,
probably because it pops up in a couple of comments when doing
a grep.
However, it was never used either, so remove it as well.
Fixes: aac6a91fea93 ("powerpc/asm: Remove unused symbols in asm-offsets.c")
Cc: Rashmica Gupta <rashmicy@gmail.com>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/asm-offsets.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index f3a662201a9f..4d230c5c7099 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -323,9 +323,6 @@ int main(void)
STACK_PT_REGS_OFFSET(GPR11, gpr[11]);
STACK_PT_REGS_OFFSET(GPR12, gpr[12]);
STACK_PT_REGS_OFFSET(GPR13, gpr[13]);
-#ifndef CONFIG_PPC64
- STACK_PT_REGS_OFFSET(GPR14, gpr[14]);
-#endif /* CONFIG_PPC64 */
/*
* Note: these symbols include _ because they overlap with special
* register names
--
2.25.0
^ permalink raw reply related
* Re: Build regressions/improvements in v5.12-rc3
From: Geert Uytterhoeven @ 2021-03-15 11:02 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, Linux Kernel Mailing List
In-Reply-To: <2c123f94-ceae-80c0-90e2-21909795eb76@csgroup.eu>
Hi Christophe,
On Mon, Mar 15, 2021 at 11:55 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
> Le 15/03/2021 à 11:49, Geert Uytterhoeven a écrit :
> > On Mon, Mar 15, 2021 at 11:46 AM Geert Uytterhoeven
> > <geert@linux-m68k.org> wrote:
> >> JFYI, when comparing v5.12-rc3[1] to v5.12-rc2[3], the summaries are:
> >> - build errors: +2/-2
> >
> >> 2 error regressions:
> >> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_248' declared with attribute error: BUILD_BUG failed: => 320:38
> >> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_249' declared with attribute error: BUILD_BUG failed: => 320:38
> >
> > powerpc-gcc4.9/ppc64_book3e_allmodconfig
> >
> > So we traded implicit declaration errors:
> >
> > - /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:
> > error: implicit declaration of function 'disable_kernel_vsx'
> > [-Werror=implicit-function-declaration]: 674:2 =>
> > - /kisskb/src/drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:
> > error: implicit declaration of function 'enable_kernel_vsx'
> > [-Werror=implicit-function-declaration]: 638:2 =>
> >
> > for compile-time assertions.
> >
>
> You are missing https://github.com/linuxppc/linux/commit/eed5fae00593ab9d261a0c1ffc1bdb786a87a55a
Which is not part of v5.12-rc3.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 1/6] selftest/mremap_test: Update the test to handle pagesize other than 4K
From: Aneesh Kumar K.V @ 2021-03-15 11:38 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: peterz, kaleshsingh, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210315113824.270796-1-aneesh.kumar@linux.ibm.com>
Instead of hardcoding 4K page size fetch it using sysconf(). For the performance
measurements test still assume 2M and 1G are hugepage sizes.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
tools/testing/selftests/vm/mremap_test.c | 113 ++++++++++++-----------
1 file changed, 61 insertions(+), 52 deletions(-)
diff --git a/tools/testing/selftests/vm/mremap_test.c b/tools/testing/selftests/vm/mremap_test.c
index 9c391d016922..c9a5461eb786 100644
--- a/tools/testing/selftests/vm/mremap_test.c
+++ b/tools/testing/selftests/vm/mremap_test.c
@@ -45,14 +45,15 @@ enum {
_4MB = 4ULL << 20,
_1GB = 1ULL << 30,
_2GB = 2ULL << 30,
- PTE = _4KB,
PMD = _2MB,
PUD = _1GB,
};
+#define PTE page_size
+
#define MAKE_TEST(source_align, destination_align, size, \
overlaps, should_fail, test_name) \
-{ \
+(struct test){ \
.name = test_name, \
.config = { \
.src_alignment = source_align, \
@@ -252,12 +253,17 @@ static int parse_args(int argc, char **argv, unsigned int *threshold_mb,
return 0;
}
+#define MAX_TEST 13
+#define MAX_PERF_TEST 3
int main(int argc, char **argv)
{
int failures = 0;
int i, run_perf_tests;
unsigned int threshold_mb = VALIDATION_DEFAULT_THRESHOLD;
unsigned int pattern_seed;
+ struct test test_cases[MAX_TEST];
+ struct test perf_test_cases[MAX_PERF_TEST];
+ int page_size;
time_t t;
pattern_seed = (unsigned int) time(&t);
@@ -268,56 +274,59 @@ int main(int argc, char **argv)
ksft_print_msg("Test configs:\n\tthreshold_mb=%u\n\tpattern_seed=%u\n\n",
threshold_mb, pattern_seed);
- struct test test_cases[] = {
- /* Expected mremap failures */
- MAKE_TEST(_4KB, _4KB, _4KB, OVERLAPPING, EXPECT_FAILURE,
- "mremap - Source and Destination Regions Overlapping"),
- MAKE_TEST(_4KB, _1KB, _4KB, NON_OVERLAPPING, EXPECT_FAILURE,
- "mremap - Destination Address Misaligned (1KB-aligned)"),
- MAKE_TEST(_1KB, _4KB, _4KB, NON_OVERLAPPING, EXPECT_FAILURE,
- "mremap - Source Address Misaligned (1KB-aligned)"),
-
- /* Src addr PTE aligned */
- MAKE_TEST(PTE, PTE, _8KB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "8KB mremap - Source PTE-aligned, Destination PTE-aligned"),
-
- /* Src addr 1MB aligned */
- MAKE_TEST(_1MB, PTE, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2MB mremap - Source 1MB-aligned, Destination PTE-aligned"),
- MAKE_TEST(_1MB, _1MB, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2MB mremap - Source 1MB-aligned, Destination 1MB-aligned"),
-
- /* Src addr PMD aligned */
- MAKE_TEST(PMD, PTE, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "4MB mremap - Source PMD-aligned, Destination PTE-aligned"),
- MAKE_TEST(PMD, _1MB, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "4MB mremap - Source PMD-aligned, Destination 1MB-aligned"),
- MAKE_TEST(PMD, PMD, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "4MB mremap - Source PMD-aligned, Destination PMD-aligned"),
-
- /* Src addr PUD aligned */
- MAKE_TEST(PUD, PTE, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination PTE-aligned"),
- MAKE_TEST(PUD, _1MB, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination 1MB-aligned"),
- MAKE_TEST(PUD, PMD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination PMD-aligned"),
- MAKE_TEST(PUD, PUD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "2GB mremap - Source PUD-aligned, Destination PUD-aligned"),
- };
-
- struct test perf_test_cases[] = {
- /*
- * mremap 1GB region - Page table level aligned time
- * comparison.
- */
- MAKE_TEST(PTE, PTE, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "1GB mremap - Source PTE-aligned, Destination PTE-aligned"),
- MAKE_TEST(PMD, PMD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "1GB mremap - Source PMD-aligned, Destination PMD-aligned"),
- MAKE_TEST(PUD, PUD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
- "1GB mremap - Source PUD-aligned, Destination PUD-aligned"),
- };
+ page_size = sysconf(_SC_PAGESIZE);
+
+ /* Expected mremap failures */
+ test_cases[0] = MAKE_TEST(page_size, page_size, page_size,
+ OVERLAPPING, EXPECT_FAILURE,
+ "mremap - Source and Destination Regions Overlapping");
+
+ test_cases[1] = MAKE_TEST(page_size, page_size/4, page_size,
+ NON_OVERLAPPING, EXPECT_FAILURE,
+ "mremap - Destination Address Misaligned (1KB-aligned)");
+ test_cases[2] = MAKE_TEST(page_size/4, page_size, page_size,
+ NON_OVERLAPPING, EXPECT_FAILURE,
+ "mremap - Source Address Misaligned (1KB-aligned)");
+
+ /* Src addr PTE aligned */
+ test_cases[3] = MAKE_TEST(PTE, PTE, PTE * 2,
+ NON_OVERLAPPING, EXPECT_SUCCESS,
+ "8KB mremap - Source PTE-aligned, Destination PTE-aligned");
+
+ /* Src addr 1MB aligned */
+ test_cases[4] = MAKE_TEST(_1MB, PTE, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2MB mremap - Source 1MB-aligned, Destination PTE-aligned");
+ test_cases[5] = MAKE_TEST(_1MB, _1MB, _2MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2MB mremap - Source 1MB-aligned, Destination 1MB-aligned");
+
+ /* Src addr PMD aligned */
+ test_cases[6] = MAKE_TEST(PMD, PTE, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "4MB mremap - Source PMD-aligned, Destination PTE-aligned");
+ test_cases[7] = MAKE_TEST(PMD, _1MB, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "4MB mremap - Source PMD-aligned, Destination 1MB-aligned");
+ test_cases[8] = MAKE_TEST(PMD, PMD, _4MB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "4MB mremap - Source PMD-aligned, Destination PMD-aligned");
+
+ /* Src addr PUD aligned */
+ test_cases[9] = MAKE_TEST(PUD, PTE, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination PTE-aligned");
+ test_cases[10] = MAKE_TEST(PUD, _1MB, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination 1MB-aligned");
+ test_cases[11] = MAKE_TEST(PUD, PMD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination PMD-aligned");
+ test_cases[12] = MAKE_TEST(PUD, PUD, _2GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "2GB mremap - Source PUD-aligned, Destination PUD-aligned");
+
+ perf_test_cases[0] = MAKE_TEST(page_size, page_size, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "1GB mremap - Source PTE-aligned, Destination PTE-aligned");
+ /*
+ * mremap 1GB region - Page table level aligned time
+ * comparison.
+ */
+ perf_test_cases[1] = MAKE_TEST(PMD, PMD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "1GB mremap - Source PMD-aligned, Destination PMD-aligned");
+ perf_test_cases[2] = MAKE_TEST(PUD, PUD, _1GB, NON_OVERLAPPING, EXPECT_SUCCESS,
+ "1GB mremap - Source PUD-aligned, Destination PUD-aligned");
run_perf_tests = (threshold_mb == VALIDATION_NO_THRESHOLD) ||
(threshold_mb * _1MB >= _1GB);
--
2.29.2
^ permalink raw reply related
* [PATCH v2 3/6] mm/mremap: Use pmd/pud_poplulate to update page table entries
From: Aneesh Kumar K.V @ 2021-03-15 11:38 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: peterz, kaleshsingh, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210315113824.270796-1-aneesh.kumar@linux.ibm.com>
pmd/pud_populate is the right interface to be used to set the respective
page table entries. Some architectures like ppc64 do assume that set_pmd/pud_at
can only be used to set a hugepage PTE. Since we are not setting up a hugepage
PTE here, use the pmd/pud_populate interface.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
mm/mremap.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/mremap.c b/mm/mremap.c
index ec8f840399ed..574287f9bb39 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -26,6 +26,7 @@
#include <asm/cacheflush.h>
#include <asm/tlbflush.h>
+#include <asm/pgalloc.h>
#include "internal.h"
@@ -257,9 +258,8 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
pmd_clear(old_pmd);
VM_BUG_ON(!pmd_none(*new_pmd));
+ pmd_populate(mm, new_pmd, (pgtable_t)pmd_page_vaddr(pmd));
- /* Set the new pmd */
- set_pmd_at(mm, new_addr, new_pmd, pmd);
flush_tlb_range(vma, old_addr, old_addr + PMD_SIZE);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
@@ -306,8 +306,7 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
VM_BUG_ON(!pud_none(*new_pud));
- /* Set the new pud */
- set_pud_at(mm, new_addr, new_pud, pud);
+ pud_populate(mm, new_pud, (pmd_t *)pud_page_vaddr(pud));
flush_tlb_range(vma, old_addr, old_addr + PUD_SIZE);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
--
2.29.2
^ permalink raw reply related
* [PATCH v2 5/6] mm/mremap: Allow arch runtime override
From: Aneesh Kumar K.V @ 2021-03-15 11:38 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: peterz, kaleshsingh, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210315113824.270796-1-aneesh.kumar@linux.ibm.com>
Architectures like ppc64 can only support faster mremap only with radix
translation. Hence allow a runtime check w.r.t support for fast mremap.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/arc/include/asm/tlb.h | 5 +++++
arch/arm64/include/asm/tlb.h | 6 ++++++
arch/powerpc/include/asm/tlb.h | 6 ++++++
arch/x86/include/asm/tlb.h | 5 +++++
mm/mremap.c | 14 +++++++++++++-
5 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/arch/arc/include/asm/tlb.h b/arch/arc/include/asm/tlb.h
index 975b35d3738d..22b8cfb46cbf 100644
--- a/arch/arc/include/asm/tlb.h
+++ b/arch/arc/include/asm/tlb.h
@@ -9,4 +9,9 @@
#include <linux/pagemap.h>
#include <asm-generic/tlb.h>
+#define arch_supports_page_tables_move arch_supports_page_tables_move
+static inline bool arch_supports_page_tables_move(void)
+{
+ return true;
+}
#endif /* _ASM_ARC_TLB_H */
diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/include/asm/tlb.h
index 61c97d3b58c7..fe209efc6a10 100644
--- a/arch/arm64/include/asm/tlb.h
+++ b/arch/arm64/include/asm/tlb.h
@@ -94,4 +94,10 @@ static inline void __pud_free_tlb(struct mmu_gather *tlb, pud_t *pudp,
}
#endif
+#define arch_supports_page_tables_move arch_supports_page_tables_move
+static inline bool arch_supports_page_tables_move(void)
+{
+ return true;
+}
+
#endif
diff --git a/arch/powerpc/include/asm/tlb.h b/arch/powerpc/include/asm/tlb.h
index 160422a439aa..058918a7cd3c 100644
--- a/arch/powerpc/include/asm/tlb.h
+++ b/arch/powerpc/include/asm/tlb.h
@@ -83,5 +83,11 @@ static inline int mm_is_thread_local(struct mm_struct *mm)
}
#endif
+#define arch_supports_page_tables_move arch_supports_page_tables_move
+static inline bool arch_supports_page_tables_move(void)
+{
+ return radix_enabled();
+}
+
#endif /* __KERNEL__ */
#endif /* __ASM_POWERPC_TLB_H */
diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h
index 1bfe979bb9bc..62915238bb36 100644
--- a/arch/x86/include/asm/tlb.h
+++ b/arch/x86/include/asm/tlb.h
@@ -37,4 +37,9 @@ static inline void __tlb_remove_table(void *table)
free_page_and_swap_cache(table);
}
+#define arch_supports_page_tables_move arch_supports_page_tables_move
+static inline bool arch_supports_page_tables_move(void)
+{
+ return true;
+}
#endif /* _ASM_X86_TLB_H */
diff --git a/mm/mremap.c b/mm/mremap.c
index fafa73b965d3..316181822cce 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -25,7 +25,7 @@
#include <linux/userfaultfd_k.h>
#include <asm/cacheflush.h>
-#include <asm/tlbflush.h>
+#include <asm/tlb.h>
#include <asm/pgalloc.h>
#include "internal.h"
@@ -210,6 +210,14 @@ static void move_ptes(struct vm_area_struct *vma, pmd_t *old_pmd,
drop_rmap_locks(vma);
}
+#ifndef arch_supports_page_tables_move
+#define arch_supports_page_tables_move arch_supports_page_tables_move
+static inline bool arch_supports_page_tables_move(void)
+{
+ return false;
+}
+#endif
+
#ifdef CONFIG_HAVE_MOVE_PMD
static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
unsigned long new_addr, pmd_t *old_pmd, pmd_t *new_pmd)
@@ -219,6 +227,8 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
struct mmu_gather tlb;
pmd_t pmd;
+ if (!arch_supports_page_tables_move())
+ return false;
/*
* The destination pmd shouldn't be established, free_pgtables()
* should have released it.
@@ -297,6 +307,8 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
struct mmu_gather tlb;
pud_t pud;
+ if (!arch_supports_page_tables_move())
+ return false;
/*
* The destination pud shouldn't be established, free_pgtables()
* should have released it.
--
2.29.2
^ permalink raw reply related
* [PATCH v2 4/6] mm/mremap: Use mmu gather interface instead of flush_tlb_range
From: Aneesh Kumar K.V @ 2021-03-15 11:38 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: peterz, kaleshsingh, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210315113824.270796-1-aneesh.kumar@linux.ibm.com>
Some architectures do have the concept of page walk cache and only mmu gather
interface supports flushing them. A fast mremap that involves moving page
table pages instead of copying pte entries should flush page walk cache since
the old translation cache is no more valid. Hence switch to mm gather to flush
TLB and mark tlb.freed_tables = 1. No page table pages need to be freed here.
With this the tlb flush is done outside page table lock (ptl).
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
mm/mremap.c | 33 +++++++++++++++++++++++++++++----
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/mm/mremap.c b/mm/mremap.c
index 574287f9bb39..fafa73b965d3 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -216,6 +216,7 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
{
spinlock_t *old_ptl, *new_ptl;
struct mm_struct *mm = vma->vm_mm;
+ struct mmu_gather tlb;
pmd_t pmd;
/*
@@ -244,11 +245,12 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
if (WARN_ON_ONCE(!pmd_none(*new_pmd)))
return false;
+ tlb_gather_mmu(&tlb, mm);
/*
* We don't have to worry about the ordering of src and dst
* ptlocks because exclusive mmap_lock prevents deadlock.
*/
- old_ptl = pmd_lock(vma->vm_mm, old_pmd);
+ old_ptl = pmd_lock(mm, old_pmd);
new_ptl = pmd_lockptr(mm, new_pmd);
if (new_ptl != old_ptl)
spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
@@ -257,13 +259,23 @@ static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
pmd = *old_pmd;
pmd_clear(old_pmd);
+ /*
+ * Mark the range. We are not freeing page table pages nor
+ * regular pages. Hence we don't need to call tlb_remove_table()
+ * or tlb_remove_page().
+ */
+ tlb_flush_pte_range(&tlb, old_addr, PMD_SIZE);
+ tlb.freed_tables = 1;
VM_BUG_ON(!pmd_none(*new_pmd));
pmd_populate(mm, new_pmd, (pgtable_t)pmd_page_vaddr(pmd));
- flush_tlb_range(vma, old_addr, old_addr + PMD_SIZE);
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
spin_unlock(old_ptl);
+ /*
+ * This will invalidate both the old TLB and page table walk caches.
+ */
+ tlb_finish_mmu(&tlb);
return true;
}
@@ -282,6 +294,7 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
{
spinlock_t *old_ptl, *new_ptl;
struct mm_struct *mm = vma->vm_mm;
+ struct mmu_gather tlb;
pud_t pud;
/*
@@ -291,11 +304,12 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
if (WARN_ON_ONCE(!pud_none(*new_pud)))
return false;
+ tlb_gather_mmu(&tlb, mm);
/*
* We don't have to worry about the ordering of src and dst
* ptlocks because exclusive mmap_lock prevents deadlock.
*/
- old_ptl = pud_lock(vma->vm_mm, old_pud);
+ old_ptl = pud_lock(mm, old_pud);
new_ptl = pud_lockptr(mm, new_pud);
if (new_ptl != old_ptl)
spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
@@ -304,14 +318,25 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
pud = *old_pud;
pud_clear(old_pud);
+ /*
+ * Mark the range. We are not freeing page table pages nor
+ * regular pages. Hence we don't need to call tlb_remove_table()
+ * or tlb_remove_page().
+ */
+ tlb_flush_pte_range(&tlb, old_addr, PUD_SIZE);
+ tlb.freed_tables = 1;
VM_BUG_ON(!pud_none(*new_pud));
pud_populate(mm, new_pud, (pmd_t *)pud_page_vaddr(pud));
- flush_tlb_range(vma, old_addr, old_addr + PUD_SIZE);
+
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
spin_unlock(old_ptl);
+ /*
+ * This will invalidate both the old TLB and page table walk caches.
+ */
+ tlb_finish_mmu(&tlb);
return true;
}
#else
--
2.29.2
^ permalink raw reply related
* [PATCH v2 2/6] selftest/mremap_test: Avoid crash with static build
From: Aneesh Kumar K.V @ 2021-03-15 11:38 UTC (permalink / raw)
To: linux-mm, akpm; +Cc: peterz, kaleshsingh, Aneesh Kumar K.V, joel, linuxppc-dev
In-Reply-To: <20210315113824.270796-1-aneesh.kumar@linux.ibm.com>
With a large mmap map size, we can overlap with the text area and using
MAP_FIXED results in unmapping that area. Switch to MAP_FIXED_NOREPLACE
and handle the EEXIST error.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
tools/testing/selftests/vm/mremap_test.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/vm/mremap_test.c b/tools/testing/selftests/vm/mremap_test.c
index c9a5461eb786..0624d1bd71b5 100644
--- a/tools/testing/selftests/vm/mremap_test.c
+++ b/tools/testing/selftests/vm/mremap_test.c
@@ -75,9 +75,10 @@ static void *get_source_mapping(struct config c)
retry:
addr += c.src_alignment;
src_addr = mmap((void *) addr, c.region_size, PROT_READ | PROT_WRITE,
- MAP_FIXED | MAP_ANONYMOUS | MAP_SHARED, -1, 0);
+ MAP_FIXED_NOREPLACE | MAP_ANONYMOUS | MAP_SHARED,
+ -1, 0);
if (src_addr == MAP_FAILED) {
- if (errno == EPERM)
+ if (errno == EPERM || errno == EEXIST)
goto retry;
goto error;
}
--
2.29.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox