in_commit_log: is the wrong token being matched for the MAINTAINERS need updating message?
Hi,
while working on a downstream version of the checkpatch.pl script used for qemu,
I experienced a "bug" that I traced back to the kernel upstream version of
checkpatch.pl, and hence the question:
what is the exact meaning of the variable in_commit_log, is it supposed to be
including the git diff stats or not?
For example, lets take this sample useless patch as input:
cut
>From 1873ba53039d8824e37452dc39af79b4b0327085 Mon Sep 17 00:00:00 2001
From: Claudio Fontana
Date: Mon, 10 Aug 2020 15:36:47 +0200
Subject: [PATCH] XXX test patch moving file
Signed-off-by: Claudio Fontana
---
sound/Makefile | 2 +-
sound/{ => ac97}/ac97_bus.c | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename sound/{ => ac97}/ac97_bus.c (100%)
diff --git a/sound/Makefile b/sound/Makefile
index 797ecdcd35e2..d7a08163ea1a 100644
--- a/sound/Makefile
+++ b/sound/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_SND) += core/ i2c/ drivers/ isa/ pci/ ppc/ arm/
sh/ synth/ usb/ \
obj-$(CONFIG_SND_AOA) += aoa/
# This one must be compilable even if sound is configured out
-obj-$(CONFIG_AC97_BUS) += ac97_bus.o
+obj-$(CONFIG_AC97_BUS) += ac97/ac97_bus.o
obj-$(CONFIG_AC97_BUS_NEW) += ac97/
ifeq ($(CONFIG_SND),y)
diff --git a/sound/ac97_bus.c b/sound/ac97/ac97_bus.c
similarity index 100%
rename from sound/ac97_bus.c
rename to sound/ac97/ac97_bus.c
--
2.16.4
cut
and using this simple patch to highlight the issue:
cut
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 599b8c4933a7..e87d5d00a9cd 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2876,16 +2876,17 @@ sub process {
}
}
+ print $line . "\n";
# Check for added, moved or deleted files
if (!$reported_maintainer_file && !$in_commit_log &&
($line =~ /^(?:new|deleted) file mode\s*\d+\s*$/ ||
$line =~ /^rename (?:from|to) [\w\/\.\-]+\s*$/ ||
($line =~ /\{\s*([\w\/\.\-]*)\s*\=\>\s*([\w\/\.\-]*)\s*\}/
&&
(defined($1) || defined($2) {
+ print("1: $1 2: $2\n");
$is_patch = 1;
$reported_maintainer_file = 1;
- WARN("FILE_PATH_CHANGES",
-"added, moved or deleted file(s), does MAINTAINERS
need updating?\n" . $herecurr);
+ print("added, moved or deleted file(s), does
MAINTAINERS need updating?\n" . $herecurr);
}
# Check for adding new DT bindings not in schema format
cut
We can see that in the sample patch input we are matching the line
sound/{ => ac97}/ac97_bus.c | 0
with the regex ($line =~ /\{\s*([\w\/\.\-]*)\s*\=\>\s*([\w\/\.\-]*)\s*\}/
Is this actually wanted?
I would expect that in this case we want instead to match the lines:
rename from sound/ac97_bus.c
rename to sound/ac97/ac97_bus.c
It does not hurt in the kernel, but it does hurt in my downstream patch, where
I try to make use of $realfile ,
which is not set if I match too early in the patch.
Would it make sense to move this chunk earlier:
# Check if it's the start of a commit log
# (not a header line and we haven't seen the patch filename)
if ($in_header_lines && $realfile =~ /^$/ &&
!($rawline =~ /^\s+(?:\S|$)/ ||
$rawline =~ /^(?:commit\b|from\b|[\w-]+:)/i)) {
$in_header_lines = 0;
$in_commit_log = 1;
$has_commit_log = 1;
}
so that the check:
if (!$reported_maintainer_file && !$in_commit_log
fails for the testcase shown (in_commit_log ends up as true), and the match
will happen later, where realfile is set and available for use?
Thanks!
Claudio
--
Claudio Fontana
Engineering Manager Virtualization, SUSE Labs Core
SUSE Software Solutions Italy Srl
[RFC] tsacct: fixup ac_pid field to contain tgid
From: Claudio Fontana
commit f3cef7a99469 ("[PATCH] csa: basic accounting over taskstats")
introduced accounting fields over taskstats,
however the ac_pid field has been filled in with the Linux pid
(the tid), instead of the POSIX pid (the tgid) like for acct.c
This change aligns the ac_pid field in tsacct with
the ac_pid field in acct.c
Signed-off-by: Claudio Fontana
---
kernel/tsacct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Hello all,
this is just to spark some responses regarding the current status
of tsacct field ac_pid, which currently is filled up with pid,
where I would expect a tgid, like for acct.c.
in acct.c:
ac.ac_pid = task_tgid_nr_ns(current, ns);
in tsacct.c:
stats->ac_pid= task_pid_nr_ns(tsk, pid_ns);
I am trying to have a low overhead way from a C userspace program
to get the tgid given a single pid.
I have tried using the tgid map provided by ftrace, however
parsing and reparsing the text of the whole map is quite expensive.
Reading from /proc/PID/ is of higher overhead, with multiple opens,
reads and close calls necessary.
I have experimented with previous work by Andrey Vagin on
task_diag (the old and the new method), but neither is currently
upstream; one of the comments at the time mentioned that the
functionality should instead be merged into netlink taskstats.
https://criu.org/Task-diag
https://lwn.net/Articles/683371/
I think that for backward compatibility reasons, this particular
change in this RFC cannot be applied as such.
Maybe adding a new field ac_tgid would be preferable?
Maybe the information could be carried inside the NETLINK
taskstat response as an unconditional additional
TASKSTATS_TYPE_TGID field, even when the TASKSTATS_CMD_GET
requests a TASKSTATS_CMD_ATTR_PID?
Thank you and looking forward for your comments,
Claudio
diff --git a/kernel/tsacct.c b/kernel/tsacct.c
index 370724b..28ecedb 100644
--- a/kernel/tsacct.c
+++ b/kernel/tsacct.c
@@ -59,7 +59,7 @@ void bacct_add_tsk(struct user_namespace *user_ns,
stats->ac_flag |= AXSIG;
stats->ac_nice = task_nice(tsk);
stats->ac_sched = tsk->policy;
- stats->ac_pid= task_pid_nr_ns(tsk, pid_ns);
+ stats->ac_pid= task_tgid_nr_ns(tsk, pid_ns);
rcu_read_lock();
tcred = __task_cred(tsk);
stats->ac_uid= from_kuid_munged(user_ns, tcred->uid);
--
2.7.4
[tip:x86/apic] x86/apic: Fix misspelled APIC
Commit-ID: 3c8fad9183ab7b3b3471fd2bb3d604104dd447cb
Gitweb: http://git.kernel.org/tip/3c8fad9183ab7b3b3471fd2bb3d604104dd447cb
Author: Claudio Fontana <claudio.font...@huawei.com>
AuthorDate: Thu, 9 Jun 2016 12:31:58 +0200
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Fri, 10 Jun 2016 14:48:24 +0200
x86/apic: Fix misspelled APIC
Signed-off-by: Claudio Fontana <claudio.font...@huawei.com>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: triv...@kernel.org
Link:
http://lkml.kernel.org/r/1465468318-19867-1-git-send-email-hw.clau...@gmail.com
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
arch/x86/kernel/apic/apic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 60078a6..f943d2f 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2045,7 +2045,7 @@ int generic_processor_info(int apicid, int version)
int thiscpu = max + disabled_cpus - 1;
pr_warning(
- "ACPI: NR_CPUS/possible_cpus limit of %i almost"
+ "APIC: NR_CPUS/possible_cpus limit of %i almost"
" reached. Keeping one slot for boot cpu."
" Processor %d/0x%x ignored.\n", max, thiscpu, apicid);
@@ -2057,7 +2057,7 @@ int generic_processor_info(int apicid, int version)
int thiscpu = max + disabled_cpus;
pr_warning(
- "ACPI: NR_CPUS/possible_cpus limit of %i reached."
+ "APIC: NR_CPUS/possible_cpus limit of %i reached."
" Processor %d/0x%x ignored.\n", max, thiscpu, apicid);
disabled_cpus++;
@@ -2085,7 +2085,7 @@ int generic_processor_info(int apicid, int version)
if (topology_update_package_map(apicid, cpu) < 0) {
int thiscpu = max + disabled_cpus;
- pr_warning("ACPI: Package limit reached. Processor %d/0x%x
ignored.\n",
+ pr_warning("APIC: Package limit reached. Processor %d/0x%x
ignored.\n",
thiscpu, apicid);
disabled_cpus++;
return -ENOSPC;
[tip:x86/apic] x86/apic: Fix misspelled APIC
Commit-ID: 3c8fad9183ab7b3b3471fd2bb3d604104dd447cb
Gitweb: http://git.kernel.org/tip/3c8fad9183ab7b3b3471fd2bb3d604104dd447cb
Author: Claudio Fontana
AuthorDate: Thu, 9 Jun 2016 12:31:58 +0200
Committer: Ingo Molnar
CommitDate: Fri, 10 Jun 2016 14:48:24 +0200
x86/apic: Fix misspelled APIC
Signed-off-by: Claudio Fontana
Signed-off-by: Thomas Gleixner
Cc: triv...@kernel.org
Link:
http://lkml.kernel.org/r/1465468318-19867-1-git-send-email-hw.clau...@gmail.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/apic/apic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 60078a6..f943d2f 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2045,7 +2045,7 @@ int generic_processor_info(int apicid, int version)
int thiscpu = max + disabled_cpus - 1;
pr_warning(
- "ACPI: NR_CPUS/possible_cpus limit of %i almost"
+ "APIC: NR_CPUS/possible_cpus limit of %i almost"
" reached. Keeping one slot for boot cpu."
" Processor %d/0x%x ignored.\n", max, thiscpu, apicid);
@@ -2057,7 +2057,7 @@ int generic_processor_info(int apicid, int version)
int thiscpu = max + disabled_cpus;
pr_warning(
- "ACPI: NR_CPUS/possible_cpus limit of %i reached."
+ "APIC: NR_CPUS/possible_cpus limit of %i reached."
" Processor %d/0x%x ignored.\n", max, thiscpu, apicid);
disabled_cpus++;
@@ -2085,7 +2085,7 @@ int generic_processor_info(int apicid, int version)
if (topology_update_package_map(apicid, cpu) < 0) {
int thiscpu = max + disabled_cpus;
- pr_warning("ACPI: Package limit reached. Processor %d/0x%x
ignored.\n",
+ pr_warning("APIC: Package limit reached. Processor %d/0x%x
ignored.\n",
thiscpu, apicid);
disabled_cpus++;
return -ENOSPC;
[tip:x86/apic] x86/apic: Fix misspelled APIC
Commit-ID: 5da5b3a6fb7ebc50c2dbdfe01b140e395c792698
Gitweb: http://git.kernel.org/tip/5da5b3a6fb7ebc50c2dbdfe01b140e395c792698
Author: Claudio Fontana <claudio.font...@huawei.com>
AuthorDate: Thu, 9 Jun 2016 12:31:58 +0200
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate: Fri, 10 Jun 2016 11:43:53 +0200
x86/apic: Fix misspelled APIC
Signed-off-by: Claudio Fontana <claudio.font...@huawei.com>
Cc: triv...@kernel.org
Link:
http://lkml.kernel.org/r/1465468318-19867-1-git-send-email-hw.clau...@gmail.com
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
---
arch/x86/kernel/apic/apic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 60078a6..f943d2f 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2045,7 +2045,7 @@ int generic_processor_info(int apicid, int version)
int thiscpu = max + disabled_cpus - 1;
pr_warning(
- "ACPI: NR_CPUS/possible_cpus limit of %i almost"
+ "APIC: NR_CPUS/possible_cpus limit of %i almost"
" reached. Keeping one slot for boot cpu."
" Processor %d/0x%x ignored.\n", max, thiscpu, apicid);
@@ -2057,7 +2057,7 @@ int generic_processor_info(int apicid, int version)
int thiscpu = max + disabled_cpus;
pr_warning(
- "ACPI: NR_CPUS/possible_cpus limit of %i reached."
+ "APIC: NR_CPUS/possible_cpus limit of %i reached."
" Processor %d/0x%x ignored.\n", max, thiscpu, apicid);
disabled_cpus++;
@@ -2085,7 +2085,7 @@ int generic_processor_info(int apicid, int version)
if (topology_update_package_map(apicid, cpu) < 0) {
int thiscpu = max + disabled_cpus;
- pr_warning("ACPI: Package limit reached. Processor %d/0x%x
ignored.\n",
+ pr_warning("APIC: Package limit reached. Processor %d/0x%x
ignored.\n",
thiscpu, apicid);
disabled_cpus++;
return -ENOSPC;
[tip:x86/apic] x86/apic: Fix misspelled APIC
Commit-ID: 5da5b3a6fb7ebc50c2dbdfe01b140e395c792698
Gitweb: http://git.kernel.org/tip/5da5b3a6fb7ebc50c2dbdfe01b140e395c792698
Author: Claudio Fontana
AuthorDate: Thu, 9 Jun 2016 12:31:58 +0200
Committer: Thomas Gleixner
CommitDate: Fri, 10 Jun 2016 11:43:53 +0200
x86/apic: Fix misspelled APIC
Signed-off-by: Claudio Fontana
Cc: triv...@kernel.org
Link:
http://lkml.kernel.org/r/1465468318-19867-1-git-send-email-hw.clau...@gmail.com
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/apic.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 60078a6..f943d2f 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2045,7 +2045,7 @@ int generic_processor_info(int apicid, int version)
int thiscpu = max + disabled_cpus - 1;
pr_warning(
- "ACPI: NR_CPUS/possible_cpus limit of %i almost"
+ "APIC: NR_CPUS/possible_cpus limit of %i almost"
" reached. Keeping one slot for boot cpu."
" Processor %d/0x%x ignored.\n", max, thiscpu, apicid);
@@ -2057,7 +2057,7 @@ int generic_processor_info(int apicid, int version)
int thiscpu = max + disabled_cpus;
pr_warning(
- "ACPI: NR_CPUS/possible_cpus limit of %i reached."
+ "APIC: NR_CPUS/possible_cpus limit of %i reached."
" Processor %d/0x%x ignored.\n", max, thiscpu, apicid);
disabled_cpus++;
@@ -2085,7 +2085,7 @@ int generic_processor_info(int apicid, int version)
if (topology_update_package_map(apicid, cpu) < 0) {
int thiscpu = max + disabled_cpus;
- pr_warning("ACPI: Package limit reached. Processor %d/0x%x
ignored.\n",
+ pr_warning("APIC: Package limit reached. Processor %d/0x%x
ignored.\n",
thiscpu, apicid);
disabled_cpus++;
return -ENOSPC;
Re: [RFC] arm64: perf: associate LL with L2 cache accesses and refills
On 04.11.2015 12:39, Mark Rutland wrote: > On Wed, Nov 04, 2015 at 12:24:13PM +0100, hw.clau...@gmail.com wrote: >> From: Claudio Fontana >> >> Signed-off-by: Claudio Fontana >> Cc: Ammar Saeed >> --- >> >> Hello, > > Hi, > >> as part of some experiments with the Juno ARM64 board, we needed to get >> readings from the PMU regarding L2 Cache hits and misses, but we noticed >> that the L2 Cache Access and Refill performance counters were not hooked >> up in the perf API. We just did that, and that seems to produce correct >> results on the Juno. >> >> However I guess that these registers are not hooked up by default due to >> differences between different boards...how could this be done taking >> account of the different possible implementations? > > The events we list for PMUv3 are those which are required to be > implemented (see "D5.10.6 Required events" in ARM DDI 0487A.h). All > others (including the L2 events you add) are optional and may or may not > be implemented, so we can't expose them for all PMUv3 implementations. > > To account for different events, we will shortly be exposing separate > logical PMUs (see [1]), which will allow us to support each CPU's set > of supported events independently. That's queued in the arm64 tree [2] > currently. > > I see that per their respective TRMs, both Cortex-A53 and Cortex-A57 > support these L2 events. It looks like when I added specialised support > [3,4] I simply missed them. Fancy sending a patch to correct that? > > Thanks, > Mark. I gave a first look at the resources you provided, I am looking at the for-next/core branch you mentioned. However, when reading the Cortex-A-53 manual it seems that even for those specific CPUs the L2 Counters are optional, as the L2 Cache itself is optional. Quoting from "12.4.2 Performance Monitors Common Event Identification Register 0": Table 12-6 on page 12-10 shows the PMCEID0_EL0 bit assignments [23] 0x17 L2D_CACHE_REFILL L2 Data cache refill: 0 This event is not implemented if the Cortex-A53 processor has been configured without an L2 cache. 1 This event is implemented if the Cortex-A53 processor has been configured with an L2 cache. [22] 0x16 L2D_CACHE L2 Data cache access: 0 This event is not implemented if the Cortex-A53 processor has been configured without an L2 cache. 1 This event is implemented if the Cortex-A53 processor has been configured with an L2 cache. I don't see that we are reading this register to check whether the hardware supports those counters or not.. shouldn't we? However, I think it should be a direct consequence of L2 cache being present, so maybe we can use the existing struct cpu_cacheinfo "num_levels"? For A-57 it does not seem to be an issue since as far as I can see from the manual, the L2 cache is always present. Do I understand this correctly? Ciao, Claudio > > [1] > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374053.html > [2] > https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=for-next/core > [3] > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374052.html > [4] > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374056.html > >> I send this as an initial RFC to try to kickoff discussion about this. >> >> Thank you, >> >> Claudio Fontana >> >> arch/arm64/kernel/perf_event.c | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c >> index f9a74d4..f72f2ff 100644 >> --- a/arch/arm64/kernel/perf_event.c >> +++ b/arch/arm64/kernel/perf_event.c >> @@ -728,6 +728,11 @@ static const unsigned >> armv8_pmuv3_perf_cache_map[PERF_COUNT_HW_CACHE_MAX] >> [C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)] = >> ARMV8_PMUV3_PERFCTR_L1_DCACHE_ACCESS, >> [C(L1D)][C(OP_WRITE)][C(RESULT_MISS)] = >> ARMV8_PMUV3_PERFCTR_L1_DCACHE_REFILL, >> >> +[C(LL)][C(OP_READ)][C(RESULT_ACCESS)] = >> ARMV8_PMUV3_PERFCTR_L2_CACHE_ACCESS, >> +[C(LL)][C(OP_READ)][C(RESULT_MISS)] = >> ARMV8_PMUV3_PERFCTR_L2_CACHE_REFILL, >> +[C(LL)][C(OP_WRITE)][C(RESULT_ACCESS)] = >> ARMV8_PMUV3_PERFCTR_L2_CACHE_ACCESS, >> +[C(LL)][C(OP_WRITE)][C(RESULT_MISS)]= >> ARMV8_PMUV3_PERFCTR_L2_CACHE_REFILL, >> + >> [C(BPU)][C(OP_READ)][C(RESULT_ACCESS)] = >> ARMV8_PMUV3_PERFCTR_PC_BRANCH_PRED, >> [C(BPU)][C(OP_READ)][C(RESULT_MISS)]= >> ARMV8_PMUV3_PERFCTR_PC_BRANCH_MIS_PRED, >> [C(BPU)][C(OP_WRITE)][C(RESULT_ACCESS)] = >> ARMV8_PMUV3_PERFCTR_PC_BRANCH_PRED, >> -- >> 1.8.5.3 >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] arm64: perf: associate LL with L2 cache accesses and refills
On 04.11.2015 12:39, Mark Rutland wrote: > On Wed, Nov 04, 2015 at 12:24:13PM +0100, hw.clau...@gmail.com wrote: >> From: Claudio Fontana <claudio.font...@huawei.com> >> >> Signed-off-by: Claudio Fontana <claudio.font...@huawei.com> >> Cc: Ammar Saeed <ammar.sa...@huawei.com> >> --- >> >> Hello, > > Hi, > >> as part of some experiments with the Juno ARM64 board, we needed to get >> readings from the PMU regarding L2 Cache hits and misses, but we noticed >> that the L2 Cache Access and Refill performance counters were not hooked >> up in the perf API. We just did that, and that seems to produce correct >> results on the Juno. >> >> However I guess that these registers are not hooked up by default due to >> differences between different boards...how could this be done taking >> account of the different possible implementations? > > The events we list for PMUv3 are those which are required to be > implemented (see "D5.10.6 Required events" in ARM DDI 0487A.h). All > others (including the L2 events you add) are optional and may or may not > be implemented, so we can't expose them for all PMUv3 implementations. > > To account for different events, we will shortly be exposing separate > logical PMUs (see [1]), which will allow us to support each CPU's set > of supported events independently. That's queued in the arm64 tree [2] > currently. > > I see that per their respective TRMs, both Cortex-A53 and Cortex-A57 > support these L2 events. It looks like when I added specialised support > [3,4] I simply missed them. Fancy sending a patch to correct that? > > Thanks, > Mark. I gave a first look at the resources you provided, I am looking at the for-next/core branch you mentioned. However, when reading the Cortex-A-53 manual it seems that even for those specific CPUs the L2 Counters are optional, as the L2 Cache itself is optional. Quoting from "12.4.2 Performance Monitors Common Event Identification Register 0": Table 12-6 on page 12-10 shows the PMCEID0_EL0 bit assignments [23] 0x17 L2D_CACHE_REFILL L2 Data cache refill: 0 This event is not implemented if the Cortex-A53 processor has been configured without an L2 cache. 1 This event is implemented if the Cortex-A53 processor has been configured with an L2 cache. [22] 0x16 L2D_CACHE L2 Data cache access: 0 This event is not implemented if the Cortex-A53 processor has been configured without an L2 cache. 1 This event is implemented if the Cortex-A53 processor has been configured with an L2 cache. I don't see that we are reading this register to check whether the hardware supports those counters or not.. shouldn't we? However, I think it should be a direct consequence of L2 cache being present, so maybe we can use the existing struct cpu_cacheinfo "num_levels"? For A-57 it does not seem to be an issue since as far as I can see from the manual, the L2 cache is always present. Do I understand this correctly? Ciao, Claudio > > [1] > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374053.html > [2] > https://git.kernel.org/cgit/linux/kernel/git/arm64/linux.git/log/?h=for-next/core > [3] > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374052.html > [4] > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/374056.html > >> I send this as an initial RFC to try to kickoff discussion about this. >> >> Thank you, >> >> Claudio Fontana >> >> arch/arm64/kernel/perf_event.c | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c >> index f9a74d4..f72f2ff 100644 >> --- a/arch/arm64/kernel/perf_event.c >> +++ b/arch/arm64/kernel/perf_event.c >> @@ -728,6 +728,11 @@ static const unsigned >> armv8_pmuv3_perf_cache_map[PERF_COUNT_HW_CACHE_MAX] >> [C(L1D)][C(OP_WRITE)][C(RESULT_ACCESS)] = >> ARMV8_PMUV3_PERFCTR_L1_DCACHE_ACCESS, >> [C(L1D)][C(OP_WRITE)][C(RESULT_MISS)] = >> ARMV8_PMUV3_PERFCTR_L1_DCACHE_REFILL, >> >> +[C(LL)][C(OP_READ)][C(RESULT_ACCESS)] = >> ARMV8_PMUV3_PERFCTR_L2_CACHE_ACCESS, >> +[C(LL)][C(OP_READ)][C(RESULT_MISS)] = >> ARMV8_PMUV3_PERFCTR_L2_CACHE_REFILL, >> +[C(LL)][C(OP_WRITE)][C(RESULT_ACCESS)] = >> ARMV8_PMUV3_PERFCTR_L2_CACHE_ACCESS, >> +[C(LL)][C(OP_WRITE)][C(RESULT_MISS)]= >> ARMV8_PMUV3_PERFCTR_L2_CACHE_REFILL, >> + >> [C(BPU)][C(OP_READ)][C(RESULT_ACCESS)] = >> ARMV8_PMUV3_PERFCTR_PC_BRANCH_PRED, >> [C(BPU)][C(OP_READ)][C(RESULT_MISS)]= >> ARMV8_PMUV3_PERFCTR_PC_BRANCH_MIS_PRED, >> [C(BPU)][C(OP_WRITE)][C(RESULT_ACCESS)] = >> ARMV8_PMUV3_PERFCTR_PC_BRANCH_PRED, >> -- >> 1.8.5.3 >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: stand-alone kvmtool
On 13.02.2015 15:40, Andre Przywara wrote:
> Ciao Claudio,
>
> On 13/02/15 14:30, Claudio Fontana wrote:
>> Hello Andre,
>>
>> On 13.02.2015 11:39, Andre Przywara wrote:
>>> Hi,
>>>
>>> as I found it increasingly inconvenient to use kvmtool[1] as part of a
>>> Linux repository, I decided to give it a go and make it a stand-alone
>>> project. So I filtered all the respective commits, adjusted the paths in
>>> there (while keeping authorship and commit date, of course) and then
>>> added the missing bits to let it compile without a kernel tree nearby.
>>> The result is now available on:
>>>
>>> git://linux-arm.org/kvmtool.git
>>> http://linux-arm.org/kvmtool.git
>>
>> It builds fine on x86_64, but when I tried to crosscompile from x86_64 to
>> AArch64,
>> I get in trouble because of libfdt: I have the aarch64 libs (static and
>> shared), but how do I instruct the build system to get it from the right
>> place?
>
> You have to install them into your cross-compiler's SYSROOT.
> Get the location of that by executing
> $ ${CROSS_COMPILE}gcc -print-sysroot.
> If it's just for libfdt, it's probably the easiest to copy them
> manually, the header files into $SYSROOT/usr/include, the libraries into
> $SYSROOT/usr/lib/aarch64-linux-gnu
> That fixed it for me ;-)
Thanks!
>
> For a more robust approach you would use your distribution's packaging
> system to install the aarch64 package into $SYSROOT.
>
> Cheers,
> Andre.
I still prefer to be forced to understand things so I actually prefer the
manual route.
Ciao,
Claudio
>>
>>>
>>> You can simply check it out, type make and use "./lkvm run" for a quick
>>> test. So far I briefly tested x86-64, arm and arm64, the later two were
>>> also cross-compiled. For sure there are rough edges in there (for
>>> instance copying a few non-uapi header files into), but I deem it worthy
>>> enough to get some public comments.
>>> For me that also fixed some nasty warnings about libfdt, which now are
>>> gone due it using your system library version of it.
>>> I also managed to get rid of the libc-i386-dev dependency when compiling
>>> for x86-64, but that still needs to be cleaned up and thus is not in the
>>> current HEAD.
>>> I haven't got around to compile-test the other supported architectures,
>>> but supporting them should be as easy as copying over the uapi kvm.h
>>> header file (see the respective ARM commit). Contributions (and tests!)
>>> are welcome.
>>>
>>> Please give it a go and tell me what you think. I don't want to fork the
>>> project, so I am happy if someone "official" picks it up.
>>>
>>> Cheers,
>>> Andre.
>>>
>>> [1] https://github.com/penberg/linux-kvm/tree/master/tools/kvm
>>> ___
>>> kvmarm mailing list
>>> kvm...@lists.cs.columbia.edu
>>> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
>>>
>>
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: stand-alone kvmtool
Hello Andre, On 13.02.2015 11:39, Andre Przywara wrote: > Hi, > > as I found it increasingly inconvenient to use kvmtool[1] as part of a > Linux repository, I decided to give it a go and make it a stand-alone > project. So I filtered all the respective commits, adjusted the paths in > there (while keeping authorship and commit date, of course) and then > added the missing bits to let it compile without a kernel tree nearby. > The result is now available on: > > git://linux-arm.org/kvmtool.git > http://linux-arm.org/kvmtool.git It builds fine on x86_64, but when I tried to crosscompile from x86_64 to AArch64, I get in trouble because of libfdt: I have the aarch64 libs (static and shared), but how do I instruct the build system to get it from the right place? Thanks, Claudio > > You can simply check it out, type make and use "./lkvm run" for a quick > test. So far I briefly tested x86-64, arm and arm64, the later two were > also cross-compiled. For sure there are rough edges in there (for > instance copying a few non-uapi header files into), but I deem it worthy > enough to get some public comments. > For me that also fixed some nasty warnings about libfdt, which now are > gone due it using your system library version of it. > I also managed to get rid of the libc-i386-dev dependency when compiling > for x86-64, but that still needs to be cleaned up and thus is not in the > current HEAD. > I haven't got around to compile-test the other supported architectures, > but supporting them should be as easy as copying over the uapi kvm.h > header file (see the respective ARM commit). Contributions (and tests!) > are welcome. > > Please give it a go and tell me what you think. I don't want to fork the > project, so I am happy if someone "official" picks it up. > > Cheers, > Andre. > > [1] https://github.com/penberg/linux-kvm/tree/master/tools/kvm > ___ > kvmarm mailing list > kvm...@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/kvmarm > -- Claudio Fontana Server Virtualization Architect Huawei Technologies Duesseldorf GmbH Riesstraße 25 - 80992 München office: +49 89 158834 4135 mobile: +49 15253060158 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: stand-alone kvmtool
Hello Andre, On 13.02.2015 11:39, Andre Przywara wrote: Hi, as I found it increasingly inconvenient to use kvmtool[1] as part of a Linux repository, I decided to give it a go and make it a stand-alone project. So I filtered all the respective commits, adjusted the paths in there (while keeping authorship and commit date, of course) and then added the missing bits to let it compile without a kernel tree nearby. The result is now available on: git://linux-arm.org/kvmtool.git http://linux-arm.org/kvmtool.git It builds fine on x86_64, but when I tried to crosscompile from x86_64 to AArch64, I get in trouble because of libfdt: I have the aarch64 libs (static and shared), but how do I instruct the build system to get it from the right place? Thanks, Claudio You can simply check it out, type make and use ./lkvm run for a quick test. So far I briefly tested x86-64, arm and arm64, the later two were also cross-compiled. For sure there are rough edges in there (for instance copying a few non-uapi header files into), but I deem it worthy enough to get some public comments. For me that also fixed some nasty warnings about libfdt, which now are gone due it using your system library version of it. I also managed to get rid of the libc-i386-dev dependency when compiling for x86-64, but that still needs to be cleaned up and thus is not in the current HEAD. I haven't got around to compile-test the other supported architectures, but supporting them should be as easy as copying over the uapi kvm.h header file (see the respective ARM commit). Contributions (and tests!) are welcome. Please give it a go and tell me what you think. I don't want to fork the project, so I am happy if someone official picks it up. Cheers, Andre. [1] https://github.com/penberg/linux-kvm/tree/master/tools/kvm ___ kvmarm mailing list kvm...@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm -- Claudio Fontana Server Virtualization Architect Huawei Technologies Duesseldorf GmbH Riesstraße 25 - 80992 München office: +49 89 158834 4135 mobile: +49 15253060158 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: stand-alone kvmtool
On 13.02.2015 15:40, Andre Przywara wrote:
Ciao Claudio,
On 13/02/15 14:30, Claudio Fontana wrote:
Hello Andre,
On 13.02.2015 11:39, Andre Przywara wrote:
Hi,
as I found it increasingly inconvenient to use kvmtool[1] as part of a
Linux repository, I decided to give it a go and make it a stand-alone
project. So I filtered all the respective commits, adjusted the paths in
there (while keeping authorship and commit date, of course) and then
added the missing bits to let it compile without a kernel tree nearby.
The result is now available on:
git://linux-arm.org/kvmtool.git
http://linux-arm.org/kvmtool.git
It builds fine on x86_64, but when I tried to crosscompile from x86_64 to
AArch64,
I get in trouble because of libfdt: I have the aarch64 libs (static and
shared), but how do I instruct the build system to get it from the right
place?
You have to install them into your cross-compiler's SYSROOT.
Get the location of that by executing
$ ${CROSS_COMPILE}gcc -print-sysroot.
If it's just for libfdt, it's probably the easiest to copy them
manually, the header files into $SYSROOT/usr/include, the libraries into
$SYSROOT/usr/lib/aarch64-linux-gnu
That fixed it for me ;-)
Thanks!
For a more robust approach you would use your distribution's packaging
system to install the aarch64 package into $SYSROOT.
Cheers,
Andre.
I still prefer to be forced to understand things so I actually prefer the
manual route.
Ciao,
Claudio
You can simply check it out, type make and use ./lkvm run for a quick
test. So far I briefly tested x86-64, arm and arm64, the later two were
also cross-compiled. For sure there are rough edges in there (for
instance copying a few non-uapi header files into), but I deem it worthy
enough to get some public comments.
For me that also fixed some nasty warnings about libfdt, which now are
gone due it using your system library version of it.
I also managed to get rid of the libc-i386-dev dependency when compiling
for x86-64, but that still needs to be cleaned up and thus is not in the
current HEAD.
I haven't got around to compile-test the other supported architectures,
but supporting them should be as easy as copying over the uapi kvm.h
header file (see the respective ARM commit). Contributions (and tests!)
are welcome.
Please give it a go and tell me what you think. I don't want to fork the
project, so I am happy if someone official picks it up.
Cheers,
Andre.
[1] https://github.com/penberg/linux-kvm/tree/master/tools/kvm
___
kvmarm mailing list
kvm...@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 4] ARM: plat-versatile: move secondary CPU startup into cpuinit
Using __CPUINIT instead of __INIT puts the secondary CPU startup code into the "right" section: it will not be freed in hotplug configurations, allowing hot-add of cpus, while still getting freed in non-hotplug configs. Tested successfully on Fast-Models and on Arndale for VCPU hotplug. Signed-off-by: Claudio Fontana Tested-by: Claudio Fontana diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S index dd703ef..19fe180 100644 --- a/arch/arm/plat-versatile/headsmp.S +++ b/arch/arm/plat-versatile/headsmp.S @@ -11,7 +11,7 @@ #include #include - __INIT + __CPUINIT /* * Realview/Versatile Express specific entry point for secondary CPUs. -- 1.7.12.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 4] ARM: plat-versatile: move secondary CPU startup into cpuinit
Using __CPUINIT instead of __INIT puts the secondary CPU startup code into the right section: it will not be freed in hotplug configurations, allowing hot-add of cpus, while still getting freed in non-hotplug configs. Tested successfully on Fast-Models and on Arndale for VCPU hotplug. Signed-off-by: Claudio Fontana claudio.font...@huawei.com Tested-by: Claudio Fontana claudio.font...@huawei.com diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S index dd703ef..19fe180 100644 --- a/arch/arm/plat-versatile/headsmp.S +++ b/arch/arm/plat-versatile/headsmp.S @@ -11,7 +11,7 @@ #include linux/linkage.h #include linux/init.h - __INIT + __CPUINIT /* * Realview/Versatile Express specific entry point for secondary CPUs. -- 1.7.12.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 3] ARM: plat-versatile: move secondary CPU startup into cpuinit
Using __CPUINIT instead of __INIT puts the secondary CPU startup code into the "right" section: it will not be freed in hotplug configurations, allowing hot-add of cpus, while still getting freed in non-hotplug configs. Signed-off-by: Claudio Fontana Tested-by: Claudio Fontana diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S index dd703ef..19fe180 100644 --- a/arch/arm/plat-versatile/headsmp.S +++ b/arch/arm/plat-versatile/headsmp.S @@ -11,7 +11,7 @@ #include #include - __INIT + __CPUINIT /* * Realview/Versatile Express specific entry point for secondary CPUs. -- 1.7.12.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND 3] ARM: plat-versatile: move secondary CPU startup into cpuinit
Using __CPUINIT instead of __INIT puts the secondary CPU startup code into the right section: it will not be freed in hotplug configurations, allowing hot-add of cpus, while still getting freed in non-hotplug configs. Signed-off-by: Claudio Fontana claudio.font...@huawei.com Tested-by: Claudio Fontana claudio.font...@huawei.com diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S index dd703ef..19fe180 100644 --- a/arch/arm/plat-versatile/headsmp.S +++ b/arch/arm/plat-versatile/headsmp.S @@ -11,7 +11,7 @@ #include linux/linkage.h #include linux/init.h - __INIT + __CPUINIT /* * Realview/Versatile Express specific entry point for secondary CPUs. -- 1.7.12.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 RESEND 2] ARM: plat-versatile: move secondary CPU startup out of .init.
Using __CPUINIT instead of __INIT puts the secondary CPU startup code into the "right" section: it will not be freed in hotplug configurations, allowing hot-add of cpus, while still getting freed in non-hotplug configs. Signed-off-by: Claudio Fontana Tested-by: Claudio Fontana diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S index dd703ef..19fe180 100644 --- a/arch/arm/plat-versatile/headsmp.S +++ b/arch/arm/plat-versatile/headsmp.S @@ -11,7 +11,7 @@ #include #include - __INIT + __CPUINIT /* * Realview/Versatile Express specific entry point for secondary CPUs. -- 1.7.12.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1 RESEND 2] ARM: plat-versatile: move secondary CPU startup out of .init.
Hello, I am implementing virtual CPU hotplug for the the ARM Cortex A-15 VExpress motherboard. This is mainly a QEMU feature, which allows dynamically changing the number of CPUs in the guest. I stumbled upon a limitation in the kernel support for plat-versatile, which contains the secondary CPU startup code for the VExpress. Basically, the secondary CPU startup code is preceded by the macro __INIT, which causes the code to be freed in free_initmem() during kernel_init(). This means that any attempt at hot-booting CPUs in the guest results in VCPUs jumping to a memory address that was freed, after which the VCPU behaves erratically, as can be expected. With this patch applied, we use __CPUINIT instead of __INIT, so that the right thing happens: under CONFIG_HOTPLUG_CPU, the secondary CPU startup code is not freed, the secondary VCPUs start successfully, and it's all gardens and blue skies. Tested successfully using the ARM fast models for the Cortex-A15. -- Claudio Fontana (1): ARM: plat-versatile: move secondary CPU startup code out of .init. arch/arm/plat-versatile/headsmp.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.7.12.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1 RESEND 2] ARM: plat-versatile: move secondary CPU startup out of .init.
Hello, I am implementing virtual CPU hotplug for the the ARM Cortex A-15 VExpress motherboard. This is mainly a QEMU feature, which allows dynamically changing the number of CPUs in the guest. I stumbled upon a limitation in the kernel support for plat-versatile, which contains the secondary CPU startup code for the VExpress. Basically, the secondary CPU startup code is preceded by the macro __INIT, which causes the code to be freed in free_initmem() during kernel_init(). This means that any attempt at hot-booting CPUs in the guest results in VCPUs jumping to a memory address that was freed, after which the VCPU behaves erratically, as can be expected. With this patch applied, we use __CPUINIT instead of __INIT, so that the right thing happens: under CONFIG_HOTPLUG_CPU, the secondary CPU startup code is not freed, the secondary VCPUs start successfully, and it's all gardens and blue skies. Tested successfully using the ARM fast models for the Cortex-A15. -- Claudio Fontana (1): ARM: plat-versatile: move secondary CPU startup code out of .init. arch/arm/plat-versatile/headsmp.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.7.12.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 RESEND 2] ARM: plat-versatile: move secondary CPU startup out of .init.
Using __CPUINIT instead of __INIT puts the secondary CPU startup code into the right section: it will not be freed in hotplug configurations, allowing hot-add of cpus, while still getting freed in non-hotplug configs. Signed-off-by: Claudio Fontana claudio.font...@huawei.com Tested-by: Claudio Fontana claudio.font...@huawei.com diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S index dd703ef..19fe180 100644 --- a/arch/arm/plat-versatile/headsmp.S +++ b/arch/arm/plat-versatile/headsmp.S @@ -11,7 +11,7 @@ #include linux/linkage.h #include linux/init.h - __INIT + __CPUINIT /* * Realview/Versatile Express specific entry point for secondary CPUs. -- 1.7.12.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 RESEND] ARM: plat-versatile: move secondary CPU startup code out of .init.
Using __CPUINIT instead of __INIT puts the secondary CPU startup code into the "right" section: it will not be freed in hotplug configurations, allowing hot-add of cpus, while still getting freed in non-hotplug configs. Signed-off-by: Claudio Fontana Tested-by: Claudio Fontana diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S index dd703ef..19fe180 100644 --- a/arch/arm/plat-versatile/headsmp.S +++ b/arch/arm/plat-versatile/headsmp.S @@ -11,7 +11,7 @@ #include #include - __INIT + __CPUINIT /* * Realview/Versatile Express specific entry point for secondary CPUs. -- 1.7.12.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1 RESEND] ARM: plat-versatile: move secondary CPU startup out of .init.
Hello, I am implementing a new feature in QEMU, including virtual CPU hotplug for the the ARM Cortex A-15 VExpress motherboard. This new QEMU feature includes a new monitor command "smp_cpus_set", which allows changing the number of visible CPUs in the guest. I stumbled upon a limitation in the kernel support for plat-versatile, which contains the secondary CPU startup code for the VExpress. Basically, the secondary CPU startup code is preceded by the macro __INIT, which causes the code to be freed in free_initmem() during kernel_init(). This means that any attempt at hot-booting CPUs in the guest results in VCPUs jumping to a memory address that was freed, after which the VCPU behaves erratically, as can be expected. With this patch applied, we use __CPUINIT instead of __INIT, so that the right thing happens: under CONFIG_HOTPLUG_CPU, the secondary CPU startup code is not freed, the secondary VCPUs start successfully, and it's all gardens and blue skies. Tested successfully using the ARM fast models for the Cortex-A15. -- Claudio Fontana (1): ARM: plat-versatile: move secondary CPU startup code out of .init. arch/arm/plat-versatile/headsmp.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.7.12.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1 RESEND] ARM: plat-versatile: move secondary CPU startup out of .init.
Hello, I am implementing a new feature in QEMU, including virtual CPU hotplug for the the ARM Cortex A-15 VExpress motherboard. This new QEMU feature includes a new monitor command smp_cpus_set, which allows changing the number of visible CPUs in the guest. I stumbled upon a limitation in the kernel support for plat-versatile, which contains the secondary CPU startup code for the VExpress. Basically, the secondary CPU startup code is preceded by the macro __INIT, which causes the code to be freed in free_initmem() during kernel_init(). This means that any attempt at hot-booting CPUs in the guest results in VCPUs jumping to a memory address that was freed, after which the VCPU behaves erratically, as can be expected. With this patch applied, we use __CPUINIT instead of __INIT, so that the right thing happens: under CONFIG_HOTPLUG_CPU, the secondary CPU startup code is not freed, the secondary VCPUs start successfully, and it's all gardens and blue skies. Tested successfully using the ARM fast models for the Cortex-A15. -- Claudio Fontana (1): ARM: plat-versatile: move secondary CPU startup code out of .init. arch/arm/plat-versatile/headsmp.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.7.12.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1 RESEND] ARM: plat-versatile: move secondary CPU startup code out of .init.
Using __CPUINIT instead of __INIT puts the secondary CPU startup code into the right section: it will not be freed in hotplug configurations, allowing hot-add of cpus, while still getting freed in non-hotplug configs. Signed-off-by: Claudio Fontana claudio.font...@huawei.com Tested-by: Claudio Fontana claudio.font...@huawei.com diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S index dd703ef..19fe180 100644 --- a/arch/arm/plat-versatile/headsmp.S +++ b/arch/arm/plat-versatile/headsmp.S @@ -11,7 +11,7 @@ #include linux/linkage.h #include linux/init.h - __INIT + __CPUINIT /* * Realview/Versatile Express specific entry point for secondary CPUs. -- 1.7.12.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: plat-versatile: move secondary CPU startup code out of .init for hotplug
Using __CPUINIT instead of __INIT puts the secondary CPU startup code into the "right" section: it will not be freed in hotplug configurations, allowing hot-add of cpus, while still getting freed in non-hotplug configs. Signed-off-by: Claudio Fontana --- arch/arm/plat-versatile/headsmp.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S index dd703ef..19fe180 100644 --- a/arch/arm/plat-versatile/headsmp.S +++ b/arch/arm/plat-versatile/headsmp.S @@ -11,7 +11,7 @@ #include #include - __INIT + __CPUINIT /* * Realview/Versatile Express specific entry point for secondary CPUs. -- 1.7.12.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: plat-versatile: move secondary CPU startup code out of .init for hotplug
Using __CPUINIT instead of __INIT puts the secondary CPU startup code into the right section: it will not be freed in hotplug configurations, allowing hot-add of cpus, while still getting freed in non-hotplug configs. Signed-off-by: Claudio Fontana claudio.font...@huawei.com --- arch/arm/plat-versatile/headsmp.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/plat-versatile/headsmp.S b/arch/arm/plat-versatile/headsmp.S index dd703ef..19fe180 100644 --- a/arch/arm/plat-versatile/headsmp.S +++ b/arch/arm/plat-versatile/headsmp.S @@ -11,7 +11,7 @@ #include linux/linkage.h #include linux/init.h - __INIT + __CPUINIT /* * Realview/Versatile Express specific entry point for secondary CPUs. -- 1.7.12.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH resend 2] net/ipv4/ipconfig: add device address to a KERN_INFO message
adds a "hwaddr" to the "IP-Config: Complete" KERN_INFO message
with the dev_addr of the device selected for auto configuration.
Signed-off-by: Claudio Fontana
---
net/ipv4/ipconfig.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 798358b..d763701 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -1500,8 +1500,10 @@ static int __init ip_auto_config(void)
* Clue in the operator.
*/
pr_info("IP-Config: Complete:\n");
- pr_info(" device=%s, addr=%pI4, mask=%pI4, gw=%pI4\n",
- ic_dev->name, _myaddr, _netmask, _gateway);
+
+ pr_info(" device=%s, hwaddr=%*phC, ipaddr=%pI4, mask=%pI4,
gw=%pI4\n",
+ ic_dev->name, ic_dev->addr_len, ic_dev->dev_addr,
+ _myaddr, _netmask, _gateway);
pr_info(" host=%s, domain=%s, nis-domain=%s\n",
utsname()->nodename, ic_domain, utsname()->domainname);
pr_info(" bootserver=%pI4, rootserver=%pI4, rootpath=%s",
--
1.7.4.4
I tried to disable the mail client unwanted features.
I hope it works this time.. sorry for that.
Claudio Fontana
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net/ipv4/ipconfig: add device address to a KERN_INFO message
adds a "hwaddr" to the "IP-Config: Complete" KERN_INFO message
with the dev_addr of the device selected for auto configuration.
Signed-off-by: Claudio Fontana
---
net/ipv4/ipconfig.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c
index 798358b..d763701 100644
--- a/net/ipv4/ipconfig.c
+++ b/net/ipv4/ipconfig.c
@@ -1500,8 +1500,10 @@ static int __init ip_auto_config(void)
* Clue in the operator.
*/
pr_info("IP-Config: Complete:\n");
- pr_info(" device=%s, addr=%pI4, mask=%pI4, gw=%pI4\n",
- ic_dev->name, _myaddr, _netmask, _gateway);
+
+ pr_info(" device=%s, hwaddr=%*phC, ipaddr=%pI4, mask=%pI4,
gw=%pI4\n",
+ ic_dev->name, ic_dev->addr_len, ic_dev->dev_addr,
+ _myaddr, _netmask, _gateway);
pr_info(" host=%s, domain=%s, nis-domain=%s\n",
utsname()->nodename, ic_domain, utsname()->domainname);
pr_info(" bootserver=%pI4, rootserver=%pI4, rootpath=%s",
--
1.7.4.4
Hello,
while troubleshooting an issue I was having trying to mount the root
filesystem using nfsroot running on a software emulation (solved),
I found it useful to be able to see the selected device address in the
"IP-Config: Complete" message during boot as I was troubleshooting,
and I thought it might be good in general, and a good way to try to
submit my first patch :)
The patch is against latest mainline.
Thank you for your help and comments,
Claudio Fontana
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net/ipv4/ipconfig: add device address to a KERN_INFO message
adds a hwaddr to the IP-Config: Complete KERN_INFO message with the dev_addr of the device selected for auto configuration. Signed-off-by: Claudio Fontana claudio.font...@huawei.com --- net/ipv4/ipconfig.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c index 798358b..d763701 100644 --- a/net/ipv4/ipconfig.c +++ b/net/ipv4/ipconfig.c @@ -1500,8 +1500,10 @@ static int __init ip_auto_config(void) * Clue in the operator. */ pr_info(IP-Config: Complete:\n); - pr_info( device=%s, addr=%pI4, mask=%pI4, gw=%pI4\n, - ic_dev-name, ic_myaddr, ic_netmask, ic_gateway); + + pr_info( device=%s, hwaddr=%*phC, ipaddr=%pI4, mask=%pI4, gw=%pI4\n, + ic_dev-name, ic_dev-addr_len, ic_dev-dev_addr, + ic_myaddr, ic_netmask, ic_gateway); pr_info( host=%s, domain=%s, nis-domain=%s\n, utsname()-nodename, ic_domain, utsname()-domainname); pr_info( bootserver=%pI4, rootserver=%pI4, rootpath=%s, -- 1.7.4.4 Hello, while troubleshooting an issue I was having trying to mount the root filesystem using nfsroot running on a software emulation (solved), I found it useful to be able to see the selected device address in the IP-Config: Complete message during boot as I was troubleshooting, and I thought it might be good in general, and a good way to try to submit my first patch :) The patch is against latest mainline. Thank you for your help and comments, Claudio Fontana -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH resend 2] net/ipv4/ipconfig: add device address to a KERN_INFO message
adds a hwaddr to the IP-Config: Complete KERN_INFO message with the dev_addr of the device selected for auto configuration. Signed-off-by: Claudio Fontana claudio.font...@huawei.com --- net/ipv4/ipconfig.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/net/ipv4/ipconfig.c b/net/ipv4/ipconfig.c index 798358b..d763701 100644 --- a/net/ipv4/ipconfig.c +++ b/net/ipv4/ipconfig.c @@ -1500,8 +1500,10 @@ static int __init ip_auto_config(void) * Clue in the operator. */ pr_info(IP-Config: Complete:\n); - pr_info( device=%s, addr=%pI4, mask=%pI4, gw=%pI4\n, - ic_dev-name, ic_myaddr, ic_netmask, ic_gateway); + + pr_info( device=%s, hwaddr=%*phC, ipaddr=%pI4, mask=%pI4, gw=%pI4\n, + ic_dev-name, ic_dev-addr_len, ic_dev-dev_addr, + ic_myaddr, ic_netmask, ic_gateway); pr_info( host=%s, domain=%s, nis-domain=%s\n, utsname()-nodename, ic_domain, utsname()-domainname); pr_info( bootserver=%pI4, rootserver=%pI4, rootpath=%s, -- 1.7.4.4 I tried to disable the mail client unwanted features. I hope it works this time.. sorry for that. Claudio Fontana -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
trivial typo in CodingStyle patch
Hello, I casually noticed this trivial typo while lurking the mailing list archives: Signed-off-by: Auke Kok <[EMAIL PROTECTED]> [...] diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index f518395..3635b38 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -409,7 +409,36 @@ out: return result; } - Chapter 8: Commenting + Chapyer 8: Tests s/Chapyer/Chapter/ Claudio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
trivial typo in CodingStyle patch
Hello, I casually noticed this trivial typo while lurking the mailing list archives: Signed-off-by: Auke Kok [EMAIL PROTECTED] [...] diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index f518395..3635b38 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -409,7 +409,36 @@ out: return result; } - Chapter 8: Commenting + Chapyer 8: Tests s/Chapyer/Chapter/ Claudio - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
