* Re: [v1 0/5] allow to reserve memory for normal kexec kernel
From: James Morse @ 2019-07-10 15:19 UTC (permalink / raw)
To: Pavel Tatashin
Cc: Bhupesh Sharma, James Morris, Sasha Levin, Eric Biederman,
kexec mailing list, Linux Kernel Mailing List, Jonathan Corbet,
Catalin Marinas, will, Linux Doc Mailing List, linux-arm-kernel
In-Reply-To: <CA+CK2bA40wQvX=KieE5Qg2Ny5ZyiDAAjAb9W7Phu2Ou_9r6bOA@mail.gmail.com>
Hi Pasha,
On 09/07/2019 14:07, Pavel Tatashin wrote:
>>> Enabling MMU and D-Cache for relocation would essentially require the
>>> same changes in kernel. Could you please share exactly why these were
>>> not accepted upstream into kexec-tools?
>>
>> Because '--no-checks' is a much simpler alternative.
>>
>> More of the discussion:
>> https://lore.kernel.org/linux-arm-kernel/5599813d-f83c-d154-287a-c131c48292ca@arm.com/
>>
>> While you can make purgatory a fully-fledged operating system, it doesn't really need to
>> do anything on arm64. Errata-workarounds alone are a reason not do start down this path.
>
> Thank you James. I will summaries the information gathered from the
> yesterday's/today's discussion and add it to the cover letter together
> with ARM64 tag. I think, the patch series makes sense for ARM64 only,
> unless there are other platforms that disable caching/MMU during
> relocation.
I'd prefer not to reserve additional memory for regular kexec just to avoid the relocation.
If the kernel's relocation work is so painful we can investigate doing it while the MMU is
enabled. If you can compare regular-kexec with kexec_file_load() you eliminate the
purgatory part of the work.
Thanks,
James
^ permalink raw reply
* Re: [v2 0/5] arm64: allow to reserve memory for normal kexec kernel
From: Matthias Brugger @ 2019-07-10 15:28 UTC (permalink / raw)
To: Pavel Tatashin, jmorris, sashal, ebiederm, kexec, linux-kernel,
corbet, catalin.marinas, will, linux-doc, linux-arm-kernel
In-Reply-To: <20190709182014.16052-1-pasha.tatashin@soleen.com>
On 09/07/2019 20:20, Pavel Tatashin wrote:
> Changelog
> v1 - v2
> - No changes to patches, addressed suggestion from James Morse
> to add "arm64" tag to cover letter.
> - Improved cover letter information based on discussion.
>
> Currently, it is only allowed to reserve memory for crash kernel, because
> it is a requirement in order to be able to boot into crash kernel without
> touching memory of crashed kernel is to have memory reserved.
>
> The second benefit for having memory reserved for kexec kernel is
> that it does not require a relocation after segments are loaded into
> memory.
>
> If kexec functionality is used for a fast system update, with a minimal
> downtime, the relocation of kernel + initramfs might take a significant
> portion of reboot.
>
> In fact, on the machine that we are using, that has ARM64 processor
> it takes 0.35s to relocate during kexec, thus taking 52% of kernel reboot
> time:
>
> kernel shutdown 0.03s
> relocation 0.35s
> kernel startup 0.29s
>
> Image: 13M and initramfs is 24M. If initramfs increases, the relocation
> time increases proportionally.
>
> While, it is possible to add 'kexeckernel=' parameters support to other
> architectures by modifying reserve_crashkernel(), in this series this is
> done for arm64 only.
>
I wonder if we couldn't use the crashkernel reserved memory area for that and
just add logic to kexec-tools to pass to the kernel a flag (a new magic reboot
number?) to use the crashkernel memory for that?
The kernel would then unload the crash/capture system in the reserved memory
area and reuse the latter for kexec.
This would also enable the feature for all architectures.
Regards,
Matthias
> The reason it is so slow on arm64 to relocate kernel is because the code
> that does relocation does this with MMU disabled, and thus D-Cache and
> I-Cache must also be disabled.
>
> Alternative solution is more complicated: Setup a temporary page table
> for relocation_routine and also for code from cpu_soft_restart. Perform
> relocation with MMU enabled, do cpu_soft_restart where MMU and caching
> are disabled, jump to purgatory. A similar approach was suggested for
> purgatory and was rejected due to making purgatory too complicated.
> On, the other hand hibernate does something similar already, but there
> MMU never needs to be disabled, and also by the time machine_kexec()
> is called, allocator is not available, as we can't fail to do reboot,
> so page table must be pre-allocated during kernel load time.
>
> Note: the above time is relocation time only. Purgatory usually also
> computes checksum, but that is skipped, because --no-check is used when
> kernel image is loaded via kexec.
>
> Pavel Tatashin (5):
> kexec: quiet down kexec reboot
> kexec: add resource for normal kexec region
> kexec: export common crashkernel/kexeckernel parser
> kexec: use reserved memory for normal kexec reboot
> arm64, kexec: reserve kexeckernel region
>
> .../admin-guide/kernel-parameters.txt | 7 ++
> arch/arm64/kernel/setup.c | 5 ++
> arch/arm64/mm/init.c | 83 ++++++++++++-------
> include/linux/crash_core.h | 6 ++
> include/linux/ioport.h | 1 +
> include/linux/kexec.h | 6 +-
> kernel/crash_core.c | 27 +++---
> kernel/kexec_core.c | 50 +++++++----
> 8 files changed, 127 insertions(+), 58 deletions(-)
>
^ permalink raw reply
* [PATCH v3] Documentation: filesystems: Convert jfs.txt to
From: Shobhit Kukreti @ 2019-07-10 15:29 UTC (permalink / raw)
To: Jonathan Corbet, skhan, Mauro Carvalho Chehab
Cc: linux-kernel-mentees, linux-doc, linux-kernel, willy,
Shobhit Kukreti
In-Reply-To: <20190710093323.7e5d6790@coco.lan>
This converts the plain text documentation of jfs.txt to reStructuredText
format. Added to documentation build process and verified with
make htmldocs
Signed-off-by: Shobhit Kukreti <shobhitkukreti@gmail.com>
---
Changes in v3:
1. Reverted to minimally changed jfs.rst
2. Used -M1 in git format-patch to show files as renamed
Changes in v2:
1. Removed flat-table.
2. Moved jfs.rst from filesystem to admin-guide
Documentation/admin-guide/index.rst | 1 +
.../{filesystems/jfs.txt => admin-guide/jfs.rst} | 44 ++++++++++++++--------
2 files changed, 30 insertions(+), 15 deletions(-)
rename Documentation/{filesystems/jfs.txt => admin-guide/jfs.rst} (51%)
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 8001917..2871b79 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -70,6 +70,7 @@ configure specific aspects of kernel behavior to your liking.
ras
bcache
ext4
+ jfs
pm/index
thunderbolt
LSM/index
diff --git a/Documentation/filesystems/jfs.txt b/Documentation/admin-guide/jfs.rst
similarity index 51%
rename from Documentation/filesystems/jfs.txt
rename to Documentation/admin-guide/jfs.rst
index 41fd757..9e12d93 100644
--- a/Documentation/filesystems/jfs.txt
+++ b/Documentation/admin-guide/jfs.rst
@@ -1,45 +1,59 @@
+===========================================
IBM's Journaled File System (JFS) for Linux
+===========================================
JFS Homepage: http://jfs.sourceforge.net/
The following mount options are supported:
+
(*) == default
-iocharset=name Character set to use for converting from Unicode to
+iocharset=name
+ Character set to use for converting from Unicode to
ASCII. The default is to do no conversion. Use
iocharset=utf8 for UTF-8 translations. This requires
CONFIG_NLS_UTF8 to be set in the kernel .config file.
iocharset=none specifies the default behavior explicitly.
-resize=value Resize the volume to <value> blocks. JFS only supports
+resize=value
+ Resize the volume to <value> blocks. JFS only supports
growing a volume, not shrinking it. This option is only
valid during a remount, when the volume is mounted
read-write. The resize keyword with no value will grow
the volume to the full size of the partition.
-nointegrity Do not write to the journal. The primary use of this option
+nointegrity
+ Do not write to the journal. The primary use of this option
is to allow for higher performance when restoring a volume
from backup media. The integrity of the volume is not
guaranteed if the system abnormally abends.
-integrity(*) Commit metadata changes to the journal. Use this option to
+integrity(*)
+ Commit metadata changes to the journal. Use this option to
remount a volume where the nointegrity option was
previously specified in order to restore normal behavior.
-errors=continue Keep going on a filesystem error.
-errors=remount-ro(*) Remount the filesystem read-only on an error.
-errors=panic Panic and halt the machine if an error occurs.
+errors=continue
+ Keep going on a filesystem error.
+errors=remount-ro(*)
+ Remount the filesystem read-only on an error.
+errors=panic
+ Panic and halt the machine if an error occurs.
-uid=value Override on-disk uid with specified value
-gid=value Override on-disk gid with specified value
-umask=value Override on-disk umask with specified octal value. For
- directories, the execute bit will be set if the corresponding
+uid=value
+ Override on-disk uid with specified value
+gid=value
+ Override on-disk gid with specified value
+umask=value
+ Override on-disk umask with specified octal value. For
+ directories, the execute bit will be set if the corresponding
read bit is set.
-discard=minlen This enables/disables the use of discard/TRIM commands.
-discard The discard/TRIM commands are sent to the underlying
-nodiscard(*) block device when blocks are freed. This is useful for SSD
- devices and sparse/thinly-provisioned LUNs. The FITRIM ioctl
+discard=minlen, discard/nodiscard(*)
+ This enables/disables the use of discard/TRIM commands.
+ The discard/TRIM commands are sent to the underlying
+ block device when blocks are freed. This is useful for SSD
+ devices and sparse/thinly-provisioned LUNs. The FITRIM ioctl
command is also available together with the nodiscard option.
The value of minlen specifies the minimum blockcount, when
a TRIM command to the block device is considered useful.
--
2.7.4
^ permalink raw reply related
* [PATCH v3 0/3] Documentation: virtual: convert .txt to .rst
From: Luke Nowakowski-Krijger @ 2019-07-10 15:30 UTC (permalink / raw)
To: linux-kernel-mentees
Cc: Luke Nowakowski-Krijger, pbonzini, rkrcmar, corbet, kvm,
linux-doc, linux-kernel
From: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
Converted a few documents in virtual and virtual/kvm to .rst format.
Also added toctree hooks to newly added files.
Adding hooks to the main doc tree should be in another patch series
once there are more files in the directory.
Changes in v3:
Documentation: kvm: Convert cpuid.txt to .rst
+ Added extra table entries that were in updated cpuid.txt
Changes in v2:
Documentation: kvm: Convert cpuid.txt to .rst
+ added updated Author email address
+ changed table to simpler format
- removed function bolding from v1
Documentation: virtual: Add toctree hooks
- Removed vcpu-request from hooks that was added in v1
Chanes in v1:
Documentation: kvm: Convert cpuid.txt to .rst
+ Converted doc to .rst format
Documentation: virtual: Convert paravirt_ops.txt to .rst
+ Converted doc to .rst format
Documentation: virtual: Add toctree hooks
+ Added index.rst file in virtual directory
+ Added index.rst file in virtual/kvm directory
Luke Nowakowski-Krijger (3):
Documentation: virtual: Convert paravirt_ops.txt to .rst
Documentation: kvm: Convert cpuid.txt to .rst
Documentation: virtual: Add toctree hooks
Documentation/virtual/index.rst | 18 ++
.../virtual/kvm/{cpuid.txt => cpuid.rst} | 162 ++++++++++--------
Documentation/virtual/kvm/index.rst | 11 ++
.../{paravirt_ops.txt => paravirt_ops.rst} | 19 +-
4 files changed, 129 insertions(+), 81 deletions(-)
create mode 100644 Documentation/virtual/index.rst
rename Documentation/virtual/kvm/{cpuid.txt => cpuid.rst} (13%)
create mode 100644 Documentation/virtual/kvm/index.rst
rename Documentation/virtual/{paravirt_ops.txt => paravirt_ops.rst} (65%)
--
2.20.1
^ permalink raw reply
* [PATCH v3] Documentation: filesystems: Convert ufs.txt to reStructuredText format
From: Shobhit Kukreti @ 2019-07-10 15:31 UTC (permalink / raw)
To: Jonathan Corbet, skhan, Mauro Carvalho Chehab
Cc: linux-kernel-mentees, linux-doc, linux-kernel, Shobhit Kukreti
In-Reply-To: <20190710092605.73ddee8b@coco.lan>
This converts the plain text documentation of ufs.txt to
reStructuredText format. Added to documentation build process
and verified with make htmldocs
Signed-off-by: Shobhit Kukreti <shobhitkukreti@gmail.com>
---
Changes in v3:
1. Reverted to minimally changed ufs.rst
2. Fix Minor Space Issues
3. Used -M1 in git format-patch to show files as renamed
Changes in v2:
1. Removed flat-table
2. Moved ufs.rst to admin-guide
Documentation/admin-guide/index.rst | 1 +
.../{filesystems/ufs.txt => admin-guide/ufs.rst} | 36 +++++++++++++---------
2 files changed, 23 insertions(+), 14 deletions(-)
rename Documentation/{filesystems/ufs.txt => admin-guide/ufs.rst} (69%)
diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
index 2871b79..9bfb076 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -71,6 +71,7 @@ configure specific aspects of kernel behavior to your liking.
bcache
ext4
jfs
+ ufs
pm/index
thunderbolt
LSM/index
diff --git a/Documentation/filesystems/ufs.txt b/Documentation/admin-guide/ufs.rst
similarity index 69%
rename from Documentation/filesystems/ufs.txt
rename to Documentation/admin-guide/ufs.rst
index 7a602ad..55d1529 100644
--- a/Documentation/filesystems/ufs.txt
+++ b/Documentation/admin-guide/ufs.rst
@@ -1,37 +1,45 @@
-USING UFS
+=========
+Using UFS
=========
mount -t ufs -o ufstype=type_of_ufs device dir
-UFS OPTIONS
+UFS Options
===========
ufstype=type_of_ufs
UFS is a file system widely used in different operating systems.
The problem are differences among implementations. Features of
some implementations are undocumented, so its hard to recognize
- type of ufs automatically. That's why user must specify type of
+ type of ufs automatically. That's why user must specify type of
ufs manually by mount option ufstype. Possible values are:
- old old format of ufs
+ old
+ old format of ufs
default value, supported as read-only
- 44bsd used in FreeBSD, NetBSD, OpenBSD
+ 44bsd
+ used in FreeBSD, NetBSD, OpenBSD
supported as read-write
- ufs2 used in FreeBSD 5.x
+ ufs2
+ used in FreeBSD 5.x
supported as read-write
- 5xbsd synonym for ufs2
+ 5xbsd
+ synonym for ufs2
- sun used in SunOS (Solaris)
+ sun
+ used in SunOS (Solaris)
supported as read-write
- sunx86 used in SunOS for Intel (Solarisx86)
+ sunx86
+ used in SunOS for Intel (Solarisx86)
supported as read-write
- hp used in HP-UX
+ hp
+ used in HP-UX
supported as read-only
nextstep
@@ -47,14 +55,14 @@ ufstype=type_of_ufs
supported as read-only
-POSSIBLE PROBLEMS
-=================
+Possible Problems
+-----------------
See next section, if you have any.
-BUG REPORTS
-===========
+Bug Reports
+-----------
Any ufs bug report you can send to daniel.pirkl@email.cz or
to dushistov@mail.ru (do not send partition tables bug reports).
--
2.7.4
^ permalink raw reply related
* [PATCH v3 2/3] Documentation: kvm: Convert cpuid.txt to .rst
From: Luke Nowakowski-Krijger @ 2019-07-10 15:30 UTC (permalink / raw)
To: linux-kernel-mentees
Cc: Luke Nowakowski-Krijger, pbonzini, rkrcmar, corbet, kvm,
linux-doc, linux-kernel
In-Reply-To: <20190710153054.29564-1-lnowakow@neg.ucsd.edu>
From: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
Convert cpuid.txt to .rst format to be parsable by sphinx.
Change format and spacing to make function definitions and return values
much more clear. Also added a table that is parsable by sphinx and makes
the information much more clean. Updated Author email to their new
active email address. Added license identifier with the consent of the
author.
Signed-off-by: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
---
Changes since v3:
+ added table entries that were in updated cpuid.txt
Changes since v2:
+ added updated Author email address
+ changed table to simpler format
- removed function bolding from v1
Changes since v1:
+ Converted doc to .rst format
.../virtual/kvm/{cpuid.txt => cpuid.rst} | 162 ++++++++++--------
1 file changed, 89 insertions(+), 73 deletions(-)
rename Documentation/virtual/kvm/{cpuid.txt => cpuid.rst} (13%)
diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.rst
similarity index 13%
rename from Documentation/virtual/kvm/cpuid.txt
rename to Documentation/virtual/kvm/cpuid.rst
index 2bdac528e4a2..01b081f6e7ea 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.rst
@@ -1,6 +1,10 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============
KVM CPUID bits
-Glauber Costa <glommer@redhat.com>, Red Hat Inc, 2010
-=====================================================
+==============
+
+:Author: Glauber Costa <glommer@gmail.com>
A guest running on a kvm host, can check some of its features using
cpuid. This is not always guaranteed to work, since userspace can
@@ -10,10 +14,14 @@ a guest.
KVM cpuid functions are:
function: KVM_CPUID_SIGNATURE (0x40000000)
-returns : eax = 0x40000001,
- ebx = 0x4b4d564b,
- ecx = 0x564b4d56,
- edx = 0x4d.
+
+returns::
+
+ eax = 0x40000001
+ ebx = 0x4b4d564b
+ ecx = 0x564b4d56
+ edx = 0x4d
+
Note that this value in ebx, ecx and edx corresponds to the string "KVMKVMKVM".
The value in eax corresponds to the maximum cpuid function present in this leaf,
and will be updated if more functions are added in the future.
@@ -21,71 +29,79 @@ Note also that old hosts set eax value to 0x0. This should
be interpreted as if the value was 0x40000001.
This function queries the presence of KVM cpuid leafs.
-
function: define KVM_CPUID_FEATURES (0x40000001)
-returns : ebx, ecx
- eax = an OR'ed group of (1 << flag), where each flags is:
-
-
-flag || value || meaning
-=============================================================================
-KVM_FEATURE_CLOCKSOURCE || 0 || kvmclock available at msrs
- || || 0x11 and 0x12.
-------------------------------------------------------------------------------
-KVM_FEATURE_NOP_IO_DELAY || 1 || not necessary to perform delays
- || || on PIO operations.
-------------------------------------------------------------------------------
-KVM_FEATURE_MMU_OP || 2 || deprecated.
-------------------------------------------------------------------------------
-KVM_FEATURE_CLOCKSOURCE2 || 3 || kvmclock available at msrs
- || || 0x4b564d00 and 0x4b564d01
-------------------------------------------------------------------------------
-KVM_FEATURE_ASYNC_PF || 4 || async pf can be enabled by
- || || writing to msr 0x4b564d02
-------------------------------------------------------------------------------
-KVM_FEATURE_STEAL_TIME || 5 || steal time can be enabled by
- || || writing to msr 0x4b564d03.
-------------------------------------------------------------------------------
-KVM_FEATURE_PV_EOI || 6 || paravirtualized end of interrupt
- || || handler can be enabled by writing
- || || to msr 0x4b564d04.
-------------------------------------------------------------------------------
-KVM_FEATURE_PV_UNHALT || 7 || guest checks this feature bit
- || || before enabling paravirtualized
- || || spinlock support.
-------------------------------------------------------------------------------
-KVM_FEATURE_PV_TLB_FLUSH || 9 || guest checks this feature bit
- || || before enabling paravirtualized
- || || tlb flush.
-------------------------------------------------------------------------------
-KVM_FEATURE_ASYNC_PF_VMEXIT || 10 || paravirtualized async PF VM exit
- || || can be enabled by setting bit 2
- || || when writing to msr 0x4b564d02
-------------------------------------------------------------------------------
-KVM_FEATURE_PV_SEND_IPI || 11 || guest checks this feature bit
- || || before using paravirtualized
- || || send IPIs.
-------------------------------------------------------------------------------
-KVM_FEATURE_PV_POLL_CONTROL || 12 || host-side polling on HLT can
- || || be disabled by writing
- || || to msr 0x4b564d05.
-------------------------------------------------------------------------------
-KVM_FEATURE_PV_SCHED_YIELD || 13 || guest checks this feature bit
- || || before using paravirtualized
- || || sched yield.
-------------------------------------------------------------------------------
-KVM_FEATURE_CLOCKSOURCE_STABLE_BIT || 24 || host will warn if no guest-side
- || || per-cpu warps are expected in
- || || kvmclock.
-------------------------------------------------------------------------------
-
- edx = an OR'ed group of (1 << flag), where each flags is:
-
-
-flag || value || meaning
-==================================================================================
-KVM_HINTS_REALTIME || 0 || guest checks this feature bit to
- || || determine that vCPUs are never
- || || preempted for an unlimited time,
- || || allowing optimizations
-----------------------------------------------------------------------------------
+
+returns::
+
+ ebx, ecx
+ eax = an OR'ed group of (1 << flag)
+
+where ``flag`` is defined as below:
+
+================================= =========== ================================
+flag value meaning
+================================= =========== ================================
+KVM_FEATURE_CLOCKSOURCE 0 kvmclock available at msrs
+ 0x11 and 0x12
+
+KVM_FEATURE_NOP_IO_DELAY 1 not necessary to perform delays
+ on PIO operations
+
+KVM_FEATURE_MMU_OP 2 deprecated
+
+KVM_FEATURE_CLOCKSOURCE2 3 kvmclock available at msrs
+
+ 0x4b564d00 and 0x4b564d01
+KVM_FEATURE_ASYNC_PF 4 async pf can be enabled by
+ writing to msr 0x4b564d02
+
+KVM_FEATURE_STEAL_TIME 5 steal time can be enabled by
+ writing to msr 0x4b564d03
+
+KVM_FEATURE_PV_EOI 6 paravirtualized end of interrupt
+ handler can be enabled by
+ writing to msr 0x4b564d04
+
+KVM_FEATURE_PV_UNHAULT 7 guest checks this feature bit
+ before enabling paravirtualized
+ spinlock support
+
+KVM_FEATURE_PV_TLB_FLUSH 9 guest checks this feature bit
+ before enabling paravirtualized
+ tlb flush
+
+KVM_FEATURE_ASYNC_PF_VMEXIT 10 paravirtualized async PF VM EXIT
+ can be enabled by setting bit 2
+ when writing to msr 0x4b564d02
+
+KVM_FEATURE_PV_SEND_IPI 11 guest checks this feature bit
+ before enabling paravirtualized
+ sebd IPIs
+
+KVM_FEATURE_PV_POLL_CONTROL 12 host-side polling on HLT can
+ be disabled by writing
+ to msr 0x4b564d05.
+
+KVM_FEATURE_PV_SCHED_YIELD 13 guest checks this feature bit
+ before using paravirtualized
+ sched yield.
+
+KVM_FEATURE_CLOCSOURCE_STABLE_BIT 24 host will warn if no guest-side
+ per-cpu warps are expeced in
+ kvmclock
+================================= =========== ================================
+
+::
+
+ edx = an OR'ed group of (1 << flag)
+
+Where ``flag`` here is defined as below:
+
+================== ============ =================================
+flag value meaning
+================== ============ =================================
+KVM_HINTS_REALTIME 0 guest checks this feature bit to
+ determine that vCPUs are never
+ preempted for an unlimited time
+ allowing optimizations
+================== ============ =================================
--
2.20.1
^ permalink raw reply related
* [PATCH v3 3/3] Documentation: virtual: Add toctree hooks
From: Luke Nowakowski-Krijger @ 2019-07-10 15:30 UTC (permalink / raw)
To: linux-kernel-mentees
Cc: Luke Nowakowski-Krijger, pbonzini, rkrcmar, corbet, kvm,
linux-doc, linux-kernel
In-Reply-To: <20190710153054.29564-1-lnowakow@neg.ucsd.edu>
From: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
Added toctree hooks for indexing. Hooks added only for newly added
files.
The hook for the top of the tree will be added in a later patch series
when a few more substantial changes have been added.
Signed-off-by: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
---
Changes since v3:
none
Changes since v2:
- Removed vcpu-request from hooks that was added in v1
Changes since v1:
+ Added index.rst file in virtual directory
+ Added index.rst file in virtual/kvm directory
Documentation/virtual/index.rst | 18 ++++++++++++++++++
Documentation/virtual/kvm/index.rst | 11 +++++++++++
2 files changed, 29 insertions(+)
create mode 100644 Documentation/virtual/index.rst
create mode 100644 Documentation/virtual/kvm/index.rst
diff --git a/Documentation/virtual/index.rst b/Documentation/virtual/index.rst
new file mode 100644
index 000000000000..19c9fa2266f4
--- /dev/null
+++ b/Documentation/virtual/index.rst
@@ -0,0 +1,18 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================
+Linux Virtual Documentation
+===========================
+
+.. toctree::
+ :maxdepth: 2
+
+ kvm/index
+ paravirt_ops
+
+.. only:: html and subproject
+
+ Indices
+ =======
+
+ * :ref:`genindex`
diff --git a/Documentation/virtual/kvm/index.rst b/Documentation/virtual/kvm/index.rst
new file mode 100644
index 000000000000..0b206a06f5be
--- /dev/null
+++ b/Documentation/virtual/kvm/index.rst
@@ -0,0 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+KVM
+===
+
+.. toctree::
+ :maxdepth: 2
+
+ amd-memory-encryption
+ cpuid
--
2.20.1
^ permalink raw reply related
* [PATCH v3 1/3] Documentation: virtual: Convert paravirt_ops.txt to .rst
From: Luke Nowakowski-Krijger @ 2019-07-10 15:30 UTC (permalink / raw)
To: linux-kernel-mentees
Cc: Luke Nowakowski-Krijger, pbonzini, rkrcmar, corbet, kvm,
linux-doc, linux-kernel
In-Reply-To: <20190710153054.29564-1-lnowakow@neg.ucsd.edu>
From: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
Convert paravirt_opts.txt to .rst format to be able to be parsed by
sphinx.
Made some minor spacing and formatting corrections to make defintions
much more clear and easy to read. Added default kernel license to the
document.
Signed-off-by: Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu>
---
Changes since v3:
none
Changes since v2:
none
Changes since v1:
+ Converted doc to .rst format
.../{paravirt_ops.txt => paravirt_ops.rst} | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
rename Documentation/virtual/{paravirt_ops.txt => paravirt_ops.rst} (65%)
diff --git a/Documentation/virtual/paravirt_ops.txt b/Documentation/virtual/paravirt_ops.rst
similarity index 65%
rename from Documentation/virtual/paravirt_ops.txt
rename to Documentation/virtual/paravirt_ops.rst
index d4881c00e339..6b789d27cead 100644
--- a/Documentation/virtual/paravirt_ops.txt
+++ b/Documentation/virtual/paravirt_ops.rst
@@ -1,3 +1,6 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============
Paravirt_ops
============
@@ -18,15 +21,15 @@ at boot time.
pv_ops operations are classified into three categories:
- simple indirect call
- These operations correspond to high level functionality where it is
- known that the overhead of indirect call isn't very important.
+ These operations correspond to high level functionality where it is
+ known that the overhead of indirect call isn't very important.
- indirect call which allows optimization with binary patch
- Usually these operations correspond to low level critical instructions. They
- are called frequently and are performance critical. The overhead is
- very important.
+ Usually these operations correspond to low level critical instructions. They
+ are called frequently and are performance critical. The overhead is
+ very important.
- a set of macros for hand written assembly code
- Hand written assembly codes (.S files) also need paravirtualization
- because they include sensitive instructions or some of code paths in
- them are very performance critical.
+ Hand written assembly codes (.S files) also need paravirtualization
+ because they include sensitive instructions or some of code paths in
+ them are very performance critical.
--
2.20.1
^ permalink raw reply related
* Re: [v2 0/5] arm64: allow to reserve memory for normal kexec kernel
From: Pavel Tatashin @ 2019-07-10 15:53 UTC (permalink / raw)
To: Dave Young
Cc: James Morris, Sasha Levin, Eric W. Biederman, kexec mailing list,
LKML, Jonathan Corbet, Catalin Marinas, will,
Linux Doc Mailing List, Linux ARM
In-Reply-To: <20190710065953.GA4744@localhost.localdomain>
> The crashkernel reservation for kdump is a must, there are already a lot
> of different problems need to consider, for example the low and high
> memory issues, and a lot of other things. I'm not convinced to enable
> this for kexec reboot.
>
> This really looks to workaround the arm64 issue and move the
> complication to kernel.
I will be working on MMU arm64 kernel relocation solution.
Pasha
>
> > On, the other hand hibernate does something similar already, but there
> > MMU never needs to be disabled, and also by the time machine_kexec()
> > is called, allocator is not available, as we can't fail to do reboot,
> > so page table must be pre-allocated during kernel load time.
> >
> > Note: the above time is relocation time only. Purgatory usually also
> > computes checksum, but that is skipped, because --no-check is used when
> > kernel image is loaded via kexec.
> >
> > Pavel Tatashin (5):
> > kexec: quiet down kexec reboot
> > kexec: add resource for normal kexec region
> > kexec: export common crashkernel/kexeckernel parser
> > kexec: use reserved memory for normal kexec reboot
> > arm64, kexec: reserve kexeckernel region
> >
> > .../admin-guide/kernel-parameters.txt | 7 ++
> > arch/arm64/kernel/setup.c | 5 ++
> > arch/arm64/mm/init.c | 83 ++++++++++++-------
> > include/linux/crash_core.h | 6 ++
> > include/linux/ioport.h | 1 +
> > include/linux/kexec.h | 6 +-
> > kernel/crash_core.c | 27 +++---
> > kernel/kexec_core.c | 50 +++++++----
> > 8 files changed, 127 insertions(+), 58 deletions(-)
> >
> > --
> > 2.22.0
> >
> >
> > _______________________________________________
> > kexec mailing list
> > kexec@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
>
> Thanks
> Dave
^ permalink raw reply
* Re: [v2 0/5] arm64: allow to reserve memory for normal kexec kernel
From: Pavel Tatashin @ 2019-07-10 15:54 UTC (permalink / raw)
To: Bhupesh Sharma
Cc: James Morris, Sasha Levin, Eric W. Biederman, kexec mailing list,
LKML, Jonathan Corbet, Catalin Marinas, will,
Linux Doc Mailing List, Linux ARM
In-Reply-To: <d57ec270-a9dc-1820-195c-eb7ef61f9828@redhat.com>
On Wed, Jul 10, 2019 at 3:32 AM Bhupesh Sharma <bhsharma@redhat.com> wrote:
>
> Hi Pavel,
>
> On 07/09/2019 11:50 PM, Pavel Tatashin wrote:
> > Changelog
> > v1 - v2
> > - No changes to patches, addressed suggestion from James Morse
> > to add "arm64" tag to cover letter.
>
> Minor nit. Please also add PATCH to the subject line. Something like
> [PATCH v2]
OK
>
> Also will suggest to wait for atleast a couple of days before sending a
> new version of the patchset so as to give sufficient time for reviews to
> happen.
OK
>
> > - Improved cover letter information based on discussion.
>
> > Currently, it is only allowed to reserve memory for crash kernel, because
> > it is a requirement in order to be able to boot into crash kernel without
> > touching memory of crashed kernel is to have memory reserved.
>
> > The second benefit for having memory reserved for kexec kernel is
> > that it does not require a relocation after segments are loaded into
> > memory.
>
> > If kexec functionality is used for a fast system update, with a minimal
> > downtime, the relocation of kernel + initramfs might take a significant
> > portion of reboot.
> >
> > In fact, on the machine that we are using, that has ARM64 processor
> > it takes 0.35s to relocate during kexec, thus taking 52% of kernel reboot
> > time:
> >
> > kernel shutdown 0.03s
> > relocation 0.35s
> > kernel startup 0.29s
> >
> > Image: 13M and initramfs is 24M. If initramfs increases, the relocation
> > time increases proportionally.
> >
> > While, it is possible to add 'kexeckernel=' parameters support to other
> > architectures by modifying reserve_crashkernel(), in this series this is
> > done for arm64 only.
>
> Note that we normally have two dimensions to this (and similar)
> problem(s) - time we spend in relocating the kernel + initramfs v/s the
> memory space we reserve while enabling kexeckernel (in this case) in the
> primary kernel.
Yes, for our specific case (Microsoft), it is more important to faster
reboot and have 64M permanently reserved. However, after thinking
about this, I decided to go ahead, and implement MMU enabled kernel
relocation for ARM64.
>
> Just to give you an example, I have to shrink even the crashkernel
> reservation size in the primary kernel on arm64 systems running fedora
> which have very small memory footprint. I have a amazon ec2 (aarch64)
> for example which runs with 256M memory space and even enabling
> crashkernel on the same was quite a challenge :)
>
> In such a case we need to do a comparison between the space we reserve
> v/s the time we spend while relocating while doing a kexec load.
>
> Note that we recently had issues with OOM in crashkernel boot, because
> of which we had to introduce kernel command-line parameter to allow a
> user to disable device dump to reduce memory usage, see the following
> commit:
>
> a3a3031b384f ("vmcore: Add a kernel parameter novmcoredd")
>
> More on the same below ...
>
> > The reason it is so slow on arm64 to relocate kernel is because the code
> > that does relocation does this with MMU disabled, and thus D-Cache and
> > I-Cache must also be disabled.
> >
> > Alternative solution is more complicated: Setup a temporary page table
> > for relocation_routine and also for code from cpu_soft_restart. Perform
> > relocation with MMU enabled, do cpu_soft_restart where MMU and caching
> > are disabled, jump to purgatory. A similar approach was suggested for
> > purgatory and was rejected due to making purgatory too complicated.
> > On, the other hand hibernate does something similar already, but there
> > MMU never needs to be disabled, and also by the time machine_kexec()
> > is called, allocator is not available, as we can't fail to do reboot,
> > so page table must be pre-allocated during kernel load time.
>
> ... may be its time to explore this path now with a fresh mind. I know
> Pratyush tried a bit on this and now I am experimenting on the same on
> several aarch64 systems, mainly because we are really short on memory
> resources on several aarch64 systems (used in embedded/cloud domain) and
> frequently run into OOM issues even in the primary kernel.
>
> Some more comments below:
>
> 1. I recommend protecting this code under a CONFIG (CONFIG_FAST_KEXEC ?)
> option and make it dependent on ARM64 being enabled (via CONFIG_ARM64
> option) to avoid causing issues on other archs like s390, powerpc,
> x86_64 (which probably don't need these changes).
>
> Also better to make the CONFIG option disabled by default, so that we
> can avoid OOM issues in primary kernel on arm64 systems with smaller
> memory footprints. A user can enabled it, if he needs fast kexec load
> experience..
>
> 2. Also, I don't see timing results for kexec_file_load() in this cover
> letter. Can you add some results for the same here, or are they on
> similar lines?
>
> I will give this a go on some aarch64 systems at my end and come back
> with more on the kernel + initramfs relocation time v/s memory space
> taken up results.
>
> Thanks,
> Bhupesh
>
> > Note: the above time is relocation time only. Purgatory usually also
> > computes checksum, but that is skipped, because --no-check is used when
> > kernel image is loaded via kexec.
> >
> > Pavel Tatashin (5):
> > kexec: quiet down kexec reboot
> > kexec: add resource for normal kexec region
> > kexec: export common crashkernel/kexeckernel parser
> > kexec: use reserved memory for normal kexec reboot
> > arm64, kexec: reserve kexeckernel region
> >
> > .../admin-guide/kernel-parameters.txt | 7 ++
> > arch/arm64/kernel/setup.c | 5 ++
> > arch/arm64/mm/init.c | 83 ++++++++++++-------
> > include/linux/crash_core.h | 6 ++
> > include/linux/ioport.h | 1 +
> > include/linux/kexec.h | 6 +-
> > kernel/crash_core.c | 27 +++---
> > kernel/kexec_core.c | 50 +++++++----
> > 8 files changed, 127 insertions(+), 58 deletions(-)
> >
>
^ permalink raw reply
* Re: [v1 0/5] allow to reserve memory for normal kexec kernel
From: Pavel Tatashin @ 2019-07-10 15:56 UTC (permalink / raw)
To: James Morse
Cc: Bhupesh Sharma, James Morris, Sasha Levin, Eric Biederman,
kexec mailing list, Linux Kernel Mailing List, Jonathan Corbet,
Catalin Marinas, will, Linux Doc Mailing List, linux-arm-kernel
In-Reply-To: <f9bea5bd-370a-47b5-8ad1-a30bd43d6cca@arm.com>
On Wed, Jul 10, 2019 at 11:19 AM James Morse <james.morse@arm.com> wrote:
>
> Hi Pasha,
>
> On 09/07/2019 14:07, Pavel Tatashin wrote:
> >>> Enabling MMU and D-Cache for relocation would essentially require the
> >>> same changes in kernel. Could you please share exactly why these were
> >>> not accepted upstream into kexec-tools?
> >>
> >> Because '--no-checks' is a much simpler alternative.
> >>
> >> More of the discussion:
> >> https://lore.kernel.org/linux-arm-kernel/5599813d-f83c-d154-287a-c131c48292ca@arm.com/
> >>
> >> While you can make purgatory a fully-fledged operating system, it doesn't really need to
> >> do anything on arm64. Errata-workarounds alone are a reason not do start down this path.
> >
> > Thank you James. I will summaries the information gathered from the
> > yesterday's/today's discussion and add it to the cover letter together
> > with ARM64 tag. I think, the patch series makes sense for ARM64 only,
> > unless there are other platforms that disable caching/MMU during
> > relocation.
>
> I'd prefer not to reserve additional memory for regular kexec just to avoid the relocation.
> If the kernel's relocation work is so painful we can investigate doing it while the MMU is
> enabled. If you can compare regular-kexec with kexec_file_load() you eliminate the
> purgatory part of the work.
Relocation time is exactly the same for regular-kexec and
kexec_file_load(). So, the relocation is indeed painful for our case.
I am working on adding MMU enabled kernel relocation.
Pasha
^ permalink raw reply
* Re: [PATCH v3] Documentation: filesystems: Convert jfs.txt to
From: Mauro Carvalho Chehab @ 2019-07-10 15:57 UTC (permalink / raw)
To: Shobhit Kukreti
Cc: Jonathan Corbet, skhan, linux-kernel-mentees, linux-doc,
linux-kernel, willy
In-Reply-To: <1562772541-32144-1-git-send-email-shobhitkukreti@gmail.com>
Em Wed, 10 Jul 2019 08:29:01 -0700
Shobhit Kukreti <shobhitkukreti@gmail.com> escreveu:
> This converts the plain text documentation of jfs.txt to reStructuredText
> format. Added to documentation build process and verified with
> make htmldocs
>
> Signed-off-by: Shobhit Kukreti <shobhitkukreti@gmail.com>
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Changes in v3:
> 1. Reverted to minimally changed jfs.rst
> 2. Used -M1 in git format-patch to show files as renamed
>
> Changes in v2:
> 1. Removed flat-table.
> 2. Moved jfs.rst from filesystem to admin-guide
>
> Documentation/admin-guide/index.rst | 1 +
> .../{filesystems/jfs.txt => admin-guide/jfs.rst} | 44 ++++++++++++++--------
> 2 files changed, 30 insertions(+), 15 deletions(-)
> rename Documentation/{filesystems/jfs.txt => admin-guide/jfs.rst} (51%)
>
> diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
> index 8001917..2871b79 100644
> --- a/Documentation/admin-guide/index.rst
> +++ b/Documentation/admin-guide/index.rst
> @@ -70,6 +70,7 @@ configure specific aspects of kernel behavior to your liking.
> ras
> bcache
> ext4
> + jfs
> pm/index
> thunderbolt
> LSM/index
> diff --git a/Documentation/filesystems/jfs.txt b/Documentation/admin-guide/jfs.rst
> similarity index 51%
> rename from Documentation/filesystems/jfs.txt
> rename to Documentation/admin-guide/jfs.rst
> index 41fd757..9e12d93 100644
> --- a/Documentation/filesystems/jfs.txt
> +++ b/Documentation/admin-guide/jfs.rst
> @@ -1,45 +1,59 @@
> +===========================================
> IBM's Journaled File System (JFS) for Linux
> +===========================================
>
> JFS Homepage: http://jfs.sourceforge.net/
>
> The following mount options are supported:
> +
> (*) == default
>
> -iocharset=name Character set to use for converting from Unicode to
> +iocharset=name
> + Character set to use for converting from Unicode to
> ASCII. The default is to do no conversion. Use
> iocharset=utf8 for UTF-8 translations. This requires
> CONFIG_NLS_UTF8 to be set in the kernel .config file.
> iocharset=none specifies the default behavior explicitly.
>
> -resize=value Resize the volume to <value> blocks. JFS only supports
> +resize=value
> + Resize the volume to <value> blocks. JFS only supports
> growing a volume, not shrinking it. This option is only
> valid during a remount, when the volume is mounted
> read-write. The resize keyword with no value will grow
> the volume to the full size of the partition.
>
> -nointegrity Do not write to the journal. The primary use of this option
> +nointegrity
> + Do not write to the journal. The primary use of this option
> is to allow for higher performance when restoring a volume
> from backup media. The integrity of the volume is not
> guaranteed if the system abnormally abends.
>
> -integrity(*) Commit metadata changes to the journal. Use this option to
> +integrity(*)
> + Commit metadata changes to the journal. Use this option to
> remount a volume where the nointegrity option was
> previously specified in order to restore normal behavior.
>
> -errors=continue Keep going on a filesystem error.
> -errors=remount-ro(*) Remount the filesystem read-only on an error.
> -errors=panic Panic and halt the machine if an error occurs.
> +errors=continue
> + Keep going on a filesystem error.
> +errors=remount-ro(*)
> + Remount the filesystem read-only on an error.
> +errors=panic
> + Panic and halt the machine if an error occurs.
>
> -uid=value Override on-disk uid with specified value
> -gid=value Override on-disk gid with specified value
> -umask=value Override on-disk umask with specified octal value. For
> - directories, the execute bit will be set if the corresponding
> +uid=value
> + Override on-disk uid with specified value
> +gid=value
> + Override on-disk gid with specified value
> +umask=value
> + Override on-disk umask with specified octal value. For
> + directories, the execute bit will be set if the corresponding
> read bit is set.
>
> -discard=minlen This enables/disables the use of discard/TRIM commands.
> -discard The discard/TRIM commands are sent to the underlying
> -nodiscard(*) block device when blocks are freed. This is useful for SSD
> - devices and sparse/thinly-provisioned LUNs. The FITRIM ioctl
> +discard=minlen, discard/nodiscard(*)
> + This enables/disables the use of discard/TRIM commands.
> + The discard/TRIM commands are sent to the underlying
> + block device when blocks are freed. This is useful for SSD
> + devices and sparse/thinly-provisioned LUNs. The FITRIM ioctl
> command is also available together with the nodiscard option.
> The value of minlen specifies the minimum blockcount, when
> a TRIM command to the block device is considered useful.
Thanks,
Mauro
^ permalink raw reply
* Re: [v2 0/5] arm64: allow to reserve memory for normal kexec kernel
From: Pavel Tatashin @ 2019-07-10 15:58 UTC (permalink / raw)
To: Matthias Brugger
Cc: James Morris, Sasha Levin, Eric W. Biederman, kexec mailing list,
LKML, Jonathan Corbet, Catalin Marinas, will,
Linux Doc Mailing List, Linux ARM
In-Reply-To: <0a141018-c09e-56e4-6a73-45b951e8490f@gmail.com>
On Wed, Jul 10, 2019 at 11:28 AM Matthias Brugger
<matthias.bgg@gmail.com> wrote:
>
>
>
> On 09/07/2019 20:20, Pavel Tatashin wrote:
> > Changelog
> > v1 - v2
> > - No changes to patches, addressed suggestion from James Morse
> > to add "arm64" tag to cover letter.
> > - Improved cover letter information based on discussion.
> >
> > Currently, it is only allowed to reserve memory for crash kernel, because
> > it is a requirement in order to be able to boot into crash kernel without
> > touching memory of crashed kernel is to have memory reserved.
> >
> > The second benefit for having memory reserved for kexec kernel is
> > that it does not require a relocation after segments are loaded into
> > memory.
> >
> > If kexec functionality is used for a fast system update, with a minimal
> > downtime, the relocation of kernel + initramfs might take a significant
> > portion of reboot.
> >
> > In fact, on the machine that we are using, that has ARM64 processor
> > it takes 0.35s to relocate during kexec, thus taking 52% of kernel reboot
> > time:
> >
> > kernel shutdown 0.03s
> > relocation 0.35s
> > kernel startup 0.29s
> >
> > Image: 13M and initramfs is 24M. If initramfs increases, the relocation
> > time increases proportionally.
> >
> > While, it is possible to add 'kexeckernel=' parameters support to other
> > architectures by modifying reserve_crashkernel(), in this series this is
> > done for arm64 only.
> >
>
> I wonder if we couldn't use the crashkernel reserved memory area for that and
> just add logic to kexec-tools to pass to the kernel a flag (a new magic reboot
> number?) to use the crashkernel memory for that?
> The kernel would then unload the crash/capture system in the reserved memory
> area and reuse the latter for kexec.
> This would also enable the feature for all architectures.
I decided to take another route: enable MMU during kernel relocation
on ARM64. This will eliminate the problem that I am experiencing with
slow relocation.
Pasha
>
> Regards,
> Matthias
>
> > The reason it is so slow on arm64 to relocate kernel is because the code
> > that does relocation does this with MMU disabled, and thus D-Cache and
> > I-Cache must also be disabled.
> >
> > Alternative solution is more complicated: Setup a temporary page table
> > for relocation_routine and also for code from cpu_soft_restart. Perform
> > relocation with MMU enabled, do cpu_soft_restart where MMU and caching
> > are disabled, jump to purgatory. A similar approach was suggested for
> > purgatory and was rejected due to making purgatory too complicated.
> > On, the other hand hibernate does something similar already, but there
> > MMU never needs to be disabled, and also by the time machine_kexec()
> > is called, allocator is not available, as we can't fail to do reboot,
> > so page table must be pre-allocated during kernel load time.
> >
> > Note: the above time is relocation time only. Purgatory usually also
> > computes checksum, but that is skipped, because --no-check is used when
> > kernel image is loaded via kexec.
> >
> > Pavel Tatashin (5):
> > kexec: quiet down kexec reboot
> > kexec: add resource for normal kexec region
> > kexec: export common crashkernel/kexeckernel parser
> > kexec: use reserved memory for normal kexec reboot
> > arm64, kexec: reserve kexeckernel region
> >
> > .../admin-guide/kernel-parameters.txt | 7 ++
> > arch/arm64/kernel/setup.c | 5 ++
> > arch/arm64/mm/init.c | 83 ++++++++++++-------
> > include/linux/crash_core.h | 6 ++
> > include/linux/ioport.h | 1 +
> > include/linux/kexec.h | 6 +-
> > kernel/crash_core.c | 27 +++---
> > kernel/kexec_core.c | 50 +++++++----
> > 8 files changed, 127 insertions(+), 58 deletions(-)
> >
^ permalink raw reply
* Re: [PATCH v3] Documentation: filesystems: Convert ufs.txt to reStructuredText format
From: Mauro Carvalho Chehab @ 2019-07-10 15:58 UTC (permalink / raw)
To: Shobhit Kukreti
Cc: Jonathan Corbet, skhan, linux-kernel-mentees, linux-doc,
linux-kernel
In-Reply-To: <1562772683-32422-1-git-send-email-shobhitkukreti@gmail.com>
Em Wed, 10 Jul 2019 08:31:23 -0700
Shobhit Kukreti <shobhitkukreti@gmail.com> escreveu:
> This converts the plain text documentation of ufs.txt to
> reStructuredText format. Added to documentation build process
> and verified with make htmldocs
>
> Signed-off-by: Shobhit Kukreti <shobhitkukreti@gmail.com>
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> Changes in v3:
> 1. Reverted to minimally changed ufs.rst
> 2. Fix Minor Space Issues
> 3. Used -M1 in git format-patch to show files as renamed
> Changes in v2:
> 1. Removed flat-table
> 2. Moved ufs.rst to admin-guide
>
> Documentation/admin-guide/index.rst | 1 +
> .../{filesystems/ufs.txt => admin-guide/ufs.rst} | 36 +++++++++++++---------
> 2 files changed, 23 insertions(+), 14 deletions(-)
> rename Documentation/{filesystems/ufs.txt => admin-guide/ufs.rst} (69%)
>
> diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst
> index 2871b79..9bfb076 100644
> --- a/Documentation/admin-guide/index.rst
> +++ b/Documentation/admin-guide/index.rst
> @@ -71,6 +71,7 @@ configure specific aspects of kernel behavior to your liking.
> bcache
> ext4
> jfs
> + ufs
> pm/index
> thunderbolt
> LSM/index
> diff --git a/Documentation/filesystems/ufs.txt b/Documentation/admin-guide/ufs.rst
> similarity index 69%
> rename from Documentation/filesystems/ufs.txt
> rename to Documentation/admin-guide/ufs.rst
> index 7a602ad..55d1529 100644
> --- a/Documentation/filesystems/ufs.txt
> +++ b/Documentation/admin-guide/ufs.rst
> @@ -1,37 +1,45 @@
> -USING UFS
> +=========
> +Using UFS
> =========
>
> mount -t ufs -o ufstype=type_of_ufs device dir
>
>
> -UFS OPTIONS
> +UFS Options
> ===========
>
> ufstype=type_of_ufs
> UFS is a file system widely used in different operating systems.
> The problem are differences among implementations. Features of
> some implementations are undocumented, so its hard to recognize
> - type of ufs automatically. That's why user must specify type of
> + type of ufs automatically. That's why user must specify type of
> ufs manually by mount option ufstype. Possible values are:
>
> - old old format of ufs
> + old
> + old format of ufs
> default value, supported as read-only
>
> - 44bsd used in FreeBSD, NetBSD, OpenBSD
> + 44bsd
> + used in FreeBSD, NetBSD, OpenBSD
> supported as read-write
>
> - ufs2 used in FreeBSD 5.x
> + ufs2
> + used in FreeBSD 5.x
> supported as read-write
>
> - 5xbsd synonym for ufs2
> + 5xbsd
> + synonym for ufs2
>
> - sun used in SunOS (Solaris)
> + sun
> + used in SunOS (Solaris)
> supported as read-write
>
> - sunx86 used in SunOS for Intel (Solarisx86)
> + sunx86
> + used in SunOS for Intel (Solarisx86)
> supported as read-write
>
> - hp used in HP-UX
> + hp
> + used in HP-UX
> supported as read-only
>
> nextstep
> @@ -47,14 +55,14 @@ ufstype=type_of_ufs
> supported as read-only
>
>
> -POSSIBLE PROBLEMS
> -=================
> +Possible Problems
> +-----------------
>
> See next section, if you have any.
>
>
> -BUG REPORTS
> -===========
> +Bug Reports
> +-----------
>
> Any ufs bug report you can send to daniel.pirkl@email.cz or
> to dushistov@mail.ru (do not send partition tables bug reports).
Thanks,
Mauro
^ permalink raw reply
* Re: [Patch V4] Documentation: coresight: covert txt to rst
From: Mauro Carvalho Chehab @ 2019-07-10 16:01 UTC (permalink / raw)
To: Phong Tran
Cc: corbet, leo.yan, mathieu.poirier, linux-arm-kernel, linux-doc,
linux-kernel-mentees, linux-kernel, skhan, suzuki.poulose
In-Reply-To: <20190710150133.13992-1-tranmanphong@gmail.com>
Em Wed, 10 Jul 2019 22:01:33 +0700
Phong Tran <tranmanphong@gmail.com> escreveu:
> as doc-guide of kernel documentation, use Sphinx tool to
> generate the html/pdf... files.
Description looks a little bogus to me...
>
> This changes the plan text txt to rst format.
>
> Signed-off-by: Phong Tran <tranmanphong@gmail.com>
But looking at the patch itself:
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> ChangeLog:
> V2: review points from Mathieu, Jonathan
> * Add coresight-cpu-debug
> * Update MAINTAINERS file
> * Avoid use markup as much as posible
> V3: review points from Mauro
> * add the colon author, date
> * change to use ```` in the struct
> * add line for the acronyms
> V4:
> * Rebase on linux-next tree
> ---
> ...sight-cpu-debug.txt => coresight-cpu-debug.rst} | 67 ++--
> .../trace/{coresight.txt => coresight.rst} | 372 +++++++++++----------
> Documentation/trace/index.rst | 2 +
> MAINTAINERS | 4 +-
> 4 files changed, 234 insertions(+), 211 deletions(-)
> rename Documentation/trace/{coresight-cpu-debug.txt => coresight-cpu-debug.rst} (84%)
> rename Documentation/trace/{coresight.txt => coresight.rst} (56%)
>
> diff --git a/Documentation/trace/coresight-cpu-debug.txt b/Documentation/trace/coresight-cpu-debug.rst
> similarity index 84%
> rename from Documentation/trace/coresight-cpu-debug.txt
> rename to Documentation/trace/coresight-cpu-debug.rst
> index 1a660a39e3c0..993dd294b81b 100644
> --- a/Documentation/trace/coresight-cpu-debug.txt
> +++ b/Documentation/trace/coresight-cpu-debug.rst
> @@ -1,8 +1,9 @@
> - Coresight CPU Debug Module
> - ==========================
> +==========================
> +Coresight CPU Debug Module
> +==========================
>
> - Author: Leo Yan <leo.yan@linaro.org>
> - Date: April 5th, 2017
> + :Author: Leo Yan <leo.yan@linaro.org>
> + :Date: April 5th, 2017
>
> Introduction
> ------------
> @@ -69,6 +70,7 @@ Before accessing debug registers, we should ensure the clock and power domain
> have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
> Debug registers', the debug registers are spread into two domains: the debug
> domain and the CPU domain.
> +::
>
> +---------------+
> | |
> @@ -125,18 +127,21 @@ If you want to enable debugging functionality at boot time, you can add
> "coresight_cpu_debug.enable=1" to the kernel command line parameter.
>
> The driver also can work as module, so can enable the debugging when insmod
> -module:
> -# insmod coresight_cpu_debug.ko debug=1
> +module::
> +
> + # insmod coresight_cpu_debug.ko debug=1
>
> When boot time or insmod module you have not enabled the debugging, the driver
> uses the debugfs file system to provide a knob to dynamically enable or disable
> debugging:
>
> -To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable:
> -# echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable
> +To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable::
> +
> + # echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable
> +
> +To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable::
>
> -To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable:
> -# echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable
> + # echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable
>
> As explained in chapter "Clock and power domain", if you are working on one
> platform which has idle states to power off debug logic and the power
> @@ -154,34 +159,34 @@ subsystem, more specifically by using the "/dev/cpu_dma_latency"
> interface (see Documentation/power/pm_qos_interface.rst for more
> details). As specified in the PM QoS documentation the requested
> parameter will stay in effect until the file descriptor is released.
> -For example:
> +For example::
>
> -# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
> -...
> -Do some work...
> -...
> -# exec 3<>-
> + # exec 3<> /dev/cpu_dma_latency; echo 0 >&3
> + ...
> + Do some work...
> + ...
> + # exec 3<>-
>
> The same can also be done from an application program.
>
> Disable specific CPU's specific idle state from cpuidle sysfs (see
> -Documentation/admin-guide/pm/cpuidle.rst):
> -# echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
> +Documentation/admin-guide/pm/cpuidle.rst)::
>
> + # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
>
> Output format
> -------------
>
> -Here is an example of the debugging output format:
> -
> -ARM external debug module:
> -coresight-cpu-debug 850000.debug: CPU[0]:
> -coresight-cpu-debug 850000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
> -coresight-cpu-debug 850000.debug: EDPCSR: handle_IPI+0x174/0x1d8
> -coresight-cpu-debug 850000.debug: EDCIDSR: 00000000
> -coresight-cpu-debug 850000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
> -coresight-cpu-debug 852000.debug: CPU[1]:
> -coresight-cpu-debug 852000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
> -coresight-cpu-debug 852000.debug: EDPCSR: debug_notifier_call+0x23c/0x358
> -coresight-cpu-debug 852000.debug: EDCIDSR: 00000000
> -coresight-cpu-debug 852000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
> +Here is an example of the debugging output format::
> +
> + ARM external debug module:
> + coresight-cpu-debug 850000.debug: CPU[0]:
> + coresight-cpu-debug 850000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
> + coresight-cpu-debug 850000.debug: EDPCSR: handle_IPI+0x174/0x1d8
> + coresight-cpu-debug 850000.debug: EDCIDSR: 00000000
> + coresight-cpu-debug 850000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
> + coresight-cpu-debug 852000.debug: CPU[1]:
> + coresight-cpu-debug 852000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
> + coresight-cpu-debug 852000.debug: EDPCSR: debug_notifier_call+0x23c/0x358
> + coresight-cpu-debug 852000.debug: EDCIDSR: 00000000
> + coresight-cpu-debug 852000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
> diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.rst
> similarity index 56%
> rename from Documentation/trace/coresight.txt
> rename to Documentation/trace/coresight.rst
> index b027d61b27a6..72f4b7ef1bad 100644
> --- a/Documentation/trace/coresight.txt
> +++ b/Documentation/trace/coresight.rst
> @@ -1,8 +1,9 @@
> - Coresight - HW Assisted Tracing on ARM
> - ======================================
> +======================================
> +Coresight - HW Assisted Tracing on ARM
> +======================================
>
> - Author: Mathieu Poirier <mathieu.poirier@linaro.org>
> - Date: September 11th, 2014
> + :Author: Mathieu Poirier <mathieu.poirier@linaro.org>
> + :Date: September 11th, 2014
>
> Introduction
> ------------
> @@ -26,7 +27,7 @@ implementation, either storing the compressed stream in a memory buffer or
> creating an interface to the outside world where data can be transferred to a
> host without fear of filling up the onboard coresight memory buffer.
>
> -At typical coresight system would look like this:
> +At typical coresight system would look like this::
>
> *****************************************************************
> **************************** AMBA AXI ****************************===||
> @@ -95,15 +96,24 @@ Acronyms and Classification
>
> Acronyms:
>
> -PTM: Program Trace Macrocell
> -ETM: Embedded Trace Macrocell
> -STM: System trace Macrocell
> -ETB: Embedded Trace Buffer
> -ITM: Instrumentation Trace Macrocell
> -TPIU: Trace Port Interface Unit
> -TMC-ETR: Trace Memory Controller, configured as Embedded Trace Router
> -TMC-ETF: Trace Memory Controller, configured as Embedded Trace FIFO
> -CTI: Cross Trigger Interface
> +PTM:
> + Program Trace Macrocell
> +ETM:
> + Embedded Trace Macrocell
> +STM:
> + System trace Macrocell
> +ETB:
> + Embedded Trace Buffer
> +ITM:
> + Instrumentation Trace Macrocell
> +TPIU:
> + Trace Port Interface Unit
> +TMC-ETR:
> + Trace Memory Controller, configured as Embedded Trace Router
> +TMC-ETF:
> + Trace Memory Controller, configured as Embedded Trace FIFO
> +CTI:
> + Cross Trigger Interface
>
> Classification:
>
> @@ -118,7 +128,7 @@ Misc:
>
>
> Device Tree Bindings
> -----------------------
> +--------------------
>
> See Documentation/devicetree/bindings/arm/coresight.txt for details.
>
> @@ -133,79 +143,79 @@ The coresight framework provides a central point to represent, configure and
> manage coresight devices on a platform. Any coresight compliant device can
> register with the framework for as long as they use the right APIs:
>
> -struct coresight_device *coresight_register(struct coresight_desc *desc);
> -void coresight_unregister(struct coresight_device *csdev);
> +.. c:function:: struct coresight_device *coresight_register(struct coresight_desc *desc);
> +.. c:function:: void coresight_unregister(struct coresight_device *csdev);
>
> -The registering function is taking a "struct coresight_device *csdev" and
> -register the device with the core framework. The unregister function takes
> -a reference to a "struct coresight_device", obtained at registration time.
> +The registering function is taking a ``struct coresight_desc *desc`` and
> +register the device with the core framework. The unregister function takes
> +a reference to a ``struct coresight_device *csdev`` obtained at registration time.
>
> If everything goes well during the registration process the new devices will
> -show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
> +show up under /sys/bus/coresight/devices, as showns here for a TC2 platform::
>
> -root:~# ls /sys/bus/coresight/devices/
> -replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
> -20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> -root:~#
> + root:~# ls /sys/bus/coresight/devices/
> + replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
> + 20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> + root:~#
>
> -The functions take a "struct coresight_device", which looks like this:
> +The functions take a ``struct coresight_device``, which looks like this::
>
> -struct coresight_desc {
> - enum coresight_dev_type type;
> - struct coresight_dev_subtype subtype;
> - const struct coresight_ops *ops;
> - struct coresight_platform_data *pdata;
> - struct device *dev;
> - const struct attribute_group **groups;
> -};
> + struct coresight_desc {
> + enum coresight_dev_type type;
> + struct coresight_dev_subtype subtype;
> + const struct coresight_ops *ops;
> + struct coresight_platform_data *pdata;
> + struct device *dev;
> + const struct attribute_group **groups;
> + };
>
>
> The "coresight_dev_type" identifies what the device is, i.e, source link or
> sink while the "coresight_dev_subtype" will characterise that type further.
>
> -The "struct coresight_ops" is mandatory and will tell the framework how to
> +The ``struct coresight_ops`` is mandatory and will tell the framework how to
> perform base operations related to the components, each component having
> -a different set of requirement. For that "struct coresight_ops_sink",
> -"struct coresight_ops_link" and "struct coresight_ops_source" have been
> +a different set of requirement. For that ``struct coresight_ops_sink``,
> +``struct coresight_ops_link`` and ``struct coresight_ops_source`` have been
> provided.
>
> -The next field, "struct coresight_platform_data *pdata" is acquired by calling
> -"of_get_coresight_platform_data()", as part of the driver's _probe routine and
> -"struct device *dev" gets the device reference embedded in the "amba_device":
> +The next field ``struct coresight_platform_data *pdata`` is acquired by calling
> +``of_get_coresight_platform_data()``, as part of the driver's _probe routine and
> +``struct device *dev`` gets the device reference embedded in the ``amba_device``::
>
> -static int etm_probe(struct amba_device *adev, const struct amba_id *id)
> -{
> - ...
> - ...
> - drvdata->dev = &adev->dev;
> - ...
> -}
> + static int etm_probe(struct amba_device *adev, const struct amba_id *id)
> + {
> + ...
> + ...
> + drvdata->dev = &adev->dev;
> + ...
> + }
>
> Specific class of device (source, link, or sink) have generic operations
> -that can be performed on them (see "struct coresight_ops"). The
> -"**groups" is a list of sysfs entries pertaining to operations
> +that can be performed on them (see ``struct coresight_ops``). The ``**groups``
> +is a list of sysfs entries pertaining to operations
> specific to that component only. "Implementation defined" customisations are
> expected to be accessed and controlled using those entries.
>
> -
> Device Naming scheme
> -------------------------
> +--------------------
> +
> The devices that appear on the "coresight" bus were named the same as their
> parent devices, i.e, the real devices that appears on AMBA bus or the platform bus.
> Thus the names were based on the Linux Open Firmware layer naming convention,
> which follows the base physical address of the device followed by the device
> -type. e.g:
> +type. e.g::
>
> -root:~# ls /sys/bus/coresight/devices/
> - 20010000.etf 20040000.funnel 20100000.stm 22040000.etm
> - 22140000.etm 230c0000.funnel 23240000.etm 20030000.tpiu
> - 20070000.etr 20120000.replicator 220c0000.funnel
> - 23040000.etm 23140000.etm 23340000.etm
> + root:~# ls /sys/bus/coresight/devices/
> + 20010000.etf 20040000.funnel 20100000.stm 22040000.etm
> + 22140000.etm 230c0000.funnel 23240000.etm 20030000.tpiu
> + 20070000.etr 20120000.replicator 220c0000.funnel
> + 23040000.etm 23140000.etm 23340000.etm
>
> However, with the introduction of ACPI support, the names of the real
> devices are a bit cryptic and non-obvious. Thus, a new naming scheme was
> introduced to use more generic names based on the type of the device. The
> -following rules apply:
> +following rules apply::
>
> 1) Devices that are bound to CPUs, are named based on the CPU logical
> number.
> @@ -220,11 +230,11 @@ following rules apply:
>
> e.g, tmc_etf0, tmc_etr0, funnel0, funnel1
>
> -Thus, with the new scheme the devices could appear as :
> +Thus, with the new scheme the devices could appear as ::
>
> -root:~# ls /sys/bus/coresight/devices/
> - etm0 etm1 etm2 etm3 etm4 etm5 funnel0
> - funnel1 funnel2 replicator0 stm0 tmc_etf0 tmc_etr0 tpiu0
> + root:~# ls /sys/bus/coresight/devices/
> + etm0 etm1 etm2 etm3 etm4 etm5 funnel0
> + funnel1 funnel2 replicator0 stm0 tmc_etf0 tmc_etr0 tpiu0
>
> Some of the examples below might refer to old naming scheme and some
> to the newer scheme, to give a confirmation that what you see on your
> @@ -234,9 +244,12 @@ the system under specified locations.
> How to use the tracer modules
> -----------------------------
>
> -There are two ways to use the Coresight framework: 1) using the perf cmd line
> -tools and 2) interacting directly with the Coresight devices using the sysFS
> -interface. Preference is given to the former as using the sysFS interface
> +There are two ways to use the Coresight framework:
> +
> +1. using the perf cmd line tools.
> +2. interacting directly with the Coresight devices using the sysFS interface.
> +
> +Preference is given to the former as using the sysFS interface
> requires a deep understanding of the Coresight HW. The following sections
> provide details on using both methods.
>
> @@ -245,107 +258,107 @@ provide details on using both methods.
> Before trace collection can start, a coresight sink needs to be identified.
> There is no limit on the amount of sinks (nor sources) that can be enabled at
> any given moment. As a generic operation, all device pertaining to the sink
> -class will have an "active" entry in sysfs:
> -
> -root:/sys/bus/coresight/devices# ls
> -replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
> -20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> -root:/sys/bus/coresight/devices# ls 20010000.etb
> -enable_sink status trigger_cntr
> -root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
> -root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
> -1
> -root:/sys/bus/coresight/devices#
> +class will have an "active" entry in sysfs::
> +
> + root:/sys/bus/coresight/devices# ls
> + replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
> + 20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> + root:/sys/bus/coresight/devices# ls 20010000.etb
> + enable_sink status trigger_cntr
> + root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
> + root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
> + 1
> + root:/sys/bus/coresight/devices#
>
> At boot time the current etm3x driver will configure the first address
> comparator with "_stext" and "_etext", essentially tracing any instruction
> that falls within that range. As such "enabling" a source will immediately
> -trigger a trace capture:
> -
> -root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
> -root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
> -1
> -root:/sys/bus/coresight/devices# cat 20010000.etb/status
> -Depth: 0x2000
> -Status: 0x1
> -RAM read ptr: 0x0
> -RAM wrt ptr: 0x19d3 <----- The write pointer is moving
> -Trigger cnt: 0x0
> -Control: 0x1
> -Flush status: 0x0
> -Flush ctrl: 0x2001
> -root:/sys/bus/coresight/devices#
> -
> -Trace collection is stopped the same way:
> -
> -root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source
> -root:/sys/bus/coresight/devices#
> -
> -The content of the ETB buffer can be harvested directly from /dev:
> -
> -root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \
> -of=~/cstrace.bin
> -
> -64+0 records in
> -64+0 records out
> -32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s
> -root:/sys/bus/coresight/devices#
> +trigger a trace capture::
> +
> + root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
> + root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
> + 1
> + root:/sys/bus/coresight/devices# cat 20010000.etb/status
> + Depth: 0x2000
> + Status: 0x1
> + RAM read ptr: 0x0
> + RAM wrt ptr: 0x19d3 <----- The write pointer is moving
> + Trigger cnt: 0x0
> + Control: 0x1
> + Flush status: 0x0
> + Flush ctrl: 0x2001
> + root:/sys/bus/coresight/devices#
> +
> +Trace collection is stopped the same way::
> +
> + root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source
> + root:/sys/bus/coresight/devices#
> +
> +The content of the ETB buffer can be harvested directly from /dev::
> +
> + root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \
> + of=~/cstrace.bin
> + 64+0 records in
> + 64+0 records out
> + 32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s
> + root:/sys/bus/coresight/devices#
>
> The file cstrace.bin can be decompressed using "ptm2human", DS-5 or Trace32.
>
> Following is a DS-5 output of an experimental loop that increments a variable up
> to a certain value. The example is simple and yet provides a glimpse of the
> wealth of possibilities that coresight provides.
> -
> -Info Tracing enabled
> -Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr}
> -Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc
> -Instruction 0 0x8026B544 E3A03000 false MOV r3,#0
> -Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Timestamp Timestamp: 17106715833
> -Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1
> -Instruction 0 0x8026B564 E1A0100D false MOV r1,sp
> -Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0
> -Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f
> -Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4]
> -Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368
> -Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc]
> -Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0]
> -Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4
> -Info Tracing enabled
> -Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc
> -Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
> -Timestamp Timestamp: 17107041535
> +::
> +
> + Info Tracing enabled
> + Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr}
> + Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc
> + Instruction 0 0x8026B544 E3A03000 false MOV r3,#0
> + Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Timestamp Timestamp: 17106715833
> + Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1
> + Instruction 0 0x8026B564 E1A0100D false MOV r1,sp
> + Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0
> + Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f
> + Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4]
> + Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368
> + Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc]
> + Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0]
> + Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4
> + Info Tracing enabled
> + Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc
> + Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
> + Timestamp Timestamp: 17107041535
>
> 2) Using perf framework:
>
> @@ -370,19 +383,18 @@ A Coresight PMU works the same way as any other PMU, i.e the name of the PMU is
> listed along with configuration options within forward slashes '/'. Since a
> Coresight system will typically have more than one sink, the name of the sink to
> work with needs to be specified as an event option.
> -On newer kernels the available sinks are listed in sysFS under:
> -($SYSFS)/bus/event_source/devices/cs_etm/sinks/
> +On newer kernels the available sinks are listed in sysFS under
> +($SYSFS)/bus/event_source/devices/cs_etm/sinks/::
>
> root@localhost:/sys/bus/event_source/devices/cs_etm/sinks# ls
> tmc_etf0 tmc_etr0 tpiu0
>
> On older kernels, this may need to be found from the list of coresight devices,
> -available under ($SYSFS)/bus/coresight/devices/:
> +available under ($SYSFS)/bus/coresight/devices/::
>
> root:~# ls /sys/bus/coresight/devices/
> etm0 etm1 etm2 etm3 etm4 etm5 funnel0
> funnel1 funnel2 replicator0 stm0 tmc_etf0 tmc_etr0 tpiu0
> -
> root@linaro-nano:~# perf record -e cs_etm/@tmc_etr0/u --per-thread program
>
> As mentioned above in section "Device Naming scheme", the names of the devices could
> @@ -395,14 +407,14 @@ to use for the trace session.
>
> More information on the above and other example on how to use Coresight with
> the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub
> -repository [3].
> +repository [#third]_.
>
> 2.1) AutoFDO analysis using the perf tools:
>
> perf can be used to record and analyze trace of programs.
>
> Execution can be recorded using 'perf record' with the cs_etm event,
> -specifying the name of the sink to record to, e.g:
> +specifying the name of the sink to record to, e.g::
>
> perf record -e cs_etm/@tmc_etr0/u --per-thread
>
> @@ -421,12 +433,14 @@ Generating coverage files for Feedback Directed Optimization: AutoFDO
>
> 'perf inject' accepts the --itrace option in which case tracing data is
> removed and replaced with the synthesized events. e.g.
> +::
>
> perf inject --itrace --strip -i perf.data -o perf.data.new
>
> Below is an example of using ARM ETM for autoFDO. It requires autofdo
> (https://github.com/google/autofdo) and gcc version 5. The bubble
> sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tutorial).
> +::
>
> $ gcc-5 -O3 sort.c -o sort
> $ taskset -c 2 ./sort
> @@ -455,28 +469,30 @@ difference is that clients are driving the trace capture rather
> than the program flow through the code.
>
> As with any other CoreSight component, specifics about the STM tracer can be
> -found in sysfs with more information on each entry being found in [1]:
> +found in sysfs with more information on each entry being found in [#first]_::
>
> -root@genericarmv8:~# ls /sys/bus/coresight/devices/stm0
> -enable_source hwevent_select port_enable subsystem uevent
> -hwevent_enable mgmt port_select traceid
> -root@genericarmv8:~#
> + root@genericarmv8:~# ls /sys/bus/coresight/devices/stm0
> + enable_source hwevent_select port_enable subsystem uevent
> + hwevent_enable mgmt port_select traceid
> + root@genericarmv8:~#
>
> Like any other source a sink needs to be identified and the STM enabled before
> -being used:
> +being used::
>
> -root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
> -root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/stm0/enable_source
> + root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
> + root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/stm0/enable_source
>
> From there user space applications can request and use channels using the devfs
> -interface provided for that purpose by the generic STM API:
> +interface provided for that purpose by the generic STM API::
> +
> + root@genericarmv8:~# ls -l /dev/stm0
> + crw------- 1 root root 10, 61 Jan 3 18:11 /dev/stm0
> + root@genericarmv8:~#
> +
> +Details on how to use the generic STM API can be found here [#second]_.
>
> -root@genericarmv8:~# ls -l /dev/stm0
> -crw------- 1 root root 10, 61 Jan 3 18:11 /dev/stm0
> -root@genericarmv8:~#
> +.. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>
> -Details on how to use the generic STM API can be found here [2].
> +.. [#second] Documentation/trace/stm.rst
>
> -[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
> -[2]. Documentation/trace/stm.rst
> -[3]. https://github.com/Linaro/perf-opencsd
> +.. [#third] https://github.com/Linaro/perf-opencsd
> diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst
> index 6b4107cf4b98..b7891cb1ab4d 100644
> --- a/Documentation/trace/index.rst
> +++ b/Documentation/trace/index.rst
> @@ -23,3 +23,5 @@ Linux Tracing Technologies
> intel_th
> stm
> sys-t
> + coresight
> + coresight-cpu-debug
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 661def85619c..eb03e5966f11 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1582,8 +1582,8 @@ R: Suzuki K Poulose <suzuki.poulose@arm.com>
> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> F: drivers/hwtracing/coresight/*
> -F: Documentation/trace/coresight.txt
> -F: Documentation/trace/coresight-cpu-debug.txt
> +F: Documentation/trace/coresight.rst
> +F: Documentation/trace/coresight-cpu-debug.rst
> F: Documentation/devicetree/bindings/arm/coresight.txt
> F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
> F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v7 16/18] MAINTAINERS: add entry for KUnit the unit testing framework
From: Brendan Higgins @ 2019-07-10 20:27 UTC (permalink / raw)
To: shuah
Cc: Frank Rowand, Greg KH, Josh Poimboeuf, Kees Cook, Kieran Bingham,
Luis Chamberlain, Peter Zijlstra, Rob Herring, Stephen Boyd,
Theodore Ts'o, Masahiro Yamada, devicetree, dri-devel,
kunit-dev, open list:DOCUMENTATION, linux-fsdevel, linux-kbuild,
Linux Kernel Mailing List, open list:KERNEL SELFTEST FRAMEWORK,
linux-nvdimm, linux-um, Sasha Levin, Bird, Timothy,
Amir Goldstein, Dan Carpenter, Daniel Vetter, Jeff Dike,
Joel Stanley, Julia Lawall, Kevin Hilman, Knut Omang,
Logan Gunthorpe, Michael Ellerman, Petr Mladek, Randy Dunlap,
Richard Weinberger, David Rientjes, Steven Rostedt, wfg
In-Reply-To: <CAFd5g4595X8cM919mohQVaShs4dKWzZ_-2RVB=6SH3RdVMwuQw@mail.gmail.com>
On Tue, Jul 9, 2019 at 11:01 AM Brendan Higgins
<brendanhiggins@google.com> wrote:
>
> On Tue, Jul 9, 2019 at 7:53 AM shuah <shuah@kernel.org> wrote:
> >
> > On 7/9/19 12:30 AM, Brendan Higgins wrote:
> > > Add myself as maintainer of KUnit, the Linux kernel's unit testing
> > > framework.
> > >
> > > Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> > > Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
> > > ---
> > > MAINTAINERS | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 677ef41cb012c..48d04d180a988 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -8599,6 +8599,17 @@ S: Maintained
> > > F: tools/testing/selftests/
> > > F: Documentation/dev-tools/kselftest*
> > >
> > > +KERNEL UNIT TESTING FRAMEWORK (KUnit)
> > > +M: Brendan Higgins <brendanhiggins@google.com>
> > > +L: linux-kselftest@vger.kernel.org
> > > +L: kunit-dev@googlegroups.com
> > > +W: https://google.github.io/kunit-docs/third_party/kernel/docs/
> > > +S: Maintained
> > > +F: Documentation/dev-tools/kunit/
> > > +F: include/kunit/
> > > +F: kunit/
> > > +F: tools/testing/kunit/
> > > +
> > > KERNEL USERMODE HELPER
> > > M: Luis Chamberlain <mcgrof@kernel.org>
> > > L: linux-kernel@vger.kernel.org
> > >
> >
> > Thanks Brendan.
> >
> > I am good with this. I can take KUnit patches through kselftest
> > with your Ack.
>
> My acknowledgement? Sure! I thought we already agreed to that.
>
> Also, do we need an ack from Masahiro or Michal for the Kbuild patch
> [PATCH v7 06/18]? And an ack from Josh or Peter for the objtool patch
> [PATCH v7 08/18]?
By the way, I am guessing you have already seen it, but I uploaded a
new version to incorporate a suggestion made by Masahiro on patch
06/18. In addition, I have gotten acks on the two patches mentioned
above. So I think we are good to go.
Thanks!
^ permalink raw reply
* Greetings!
From: fuqingzheng @ 2019-07-10 5:07 UTC (permalink / raw)
To: Recipients
Good day,
I have a mutual business proposal, which refers to the transfer of a large amount of money to an account abroad, with your help as a foreign partner as a beneficiary of the funds. Everything about this transaction will be legal without any bridge of financial authority both in my country and yours. If you are interested and I will give you more information about the project as soon as I receive your positive response.
Best regards,
Executive Director.
ICBC. China
---
Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware.
https://www.avast.com/antivirus
^ permalink raw reply
* RE: [PATCH v4] Added warnings in checkpatch.pl script to :
From: Gote, Nitin R @ 2019-07-11 3:46 UTC (permalink / raw)
To: 'Joe Perches', corbet@lwn.net
Cc: akpm@linux-foundation.org, apw@canonical.com,
keescook@chromium.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com
In-Reply-To: <040b50f00501ae131256bb13a5362731ebdd6bfe.camel@perches.com>
> -----Original Message-----
> From: Joe Perches [mailto:joe@perches.com]
> Sent: Tuesday, July 9, 2019 9:40 PM
> To: Gote, Nitin R <nitin.r.gote@intel.com>; corbet@lwn.net
> Cc: akpm@linux-foundation.org; apw@canonical.com;
> keescook@chromium.org; linux-doc@vger.kernel.org; linux-
> kernel@vger.kernel.org; kernel-hardening@lists.openwall.com
> Subject: Re: [PATCH v4] Added warnings in checkpatch.pl script to :
>
> On Tue, 2019-07-09 at 21:18 +0530, NitinGote wrote:
> > From: Nitin Gote <nitin.r.gote@intel.com>
> >
> > 1. Deprecate strcpy() in favor of strscpy().
> > 2. Deprecate strlcpy() in favor of strscpy().
> > 3. Deprecate strncpy() in favor of strscpy() or strscpy_pad().
> >
> > Updated strncpy() section in Documentation/process/deprecated.rst
> > to cover strscpy_pad() case.
>
> Please slow down your patch submission rate for this instance and respond
> appropriately to the comments you've been given.
Sure, I will explore this things more. And sorry, I missed to incorporate one comment.
I will take care of such things.
>
> This stuff is not critical bug fixing.
>
Noted.
> The subject could be something like:
>
> Subject: [PATCH v#] Documentation/checkpatch: Prefer strscpy over
> strcpy/strlcpy
>
How about this :
Subject: [PATCH v#] Doc/checkpatch: Prefer strscpy/strscpy_pad over strcpy/strlcpy/strncpy
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> []
> > @@ -605,6 +605,20 @@ foreach my $entry (keys %deprecated_apis) { }
> > $deprecated_apis_search = "(?:${deprecated_apis_search})";
> >
> > +our %deprecated_string_apis = (
> > + "strcpy" => "strscpy",
> > + "strlcpy" => "strscpy",
> > + "strncpy" => "strscpy, strscpy_pad or
> for non-NUL-terminated strings, strncpy() can still be used, but destinations
> should be marked with the __nonstring",
>
> 'the' is not necessary.
Noted.
>
> There could likely also be a strscat created for strcat, strlcat and strncat.
>
I have not found reference for strscat in kernel.
Could you please give any reference for strscat ?
> btw:
>
> There were several defects in the kernel for misuses of strlcpy.
>
> Did you or anyone else have an opinion on stracpy to avoid duplicating the
> first argument in a sizeof()?
>
> strlcpy(foo, bar, sizeof(foo))
> to
> stracpy(foo, bar)
>
> where foo must be char array compatible ?
>
> https://lore.kernel.org/lkml/d1524130f91d7cfd61bc736623409693d2895f57.
> camel@perches.com/
>
>
As I understood, your trying to give new interface like stracpy(), to avoid duplication of first
argument in a sizeof(), we can also make it more robust for users by adding check or warn in
checkpatch.pl to prefer stracpy().
Did you or anyone has opinion on this ?
Thanks,
Nitin Gote
^ permalink raw reply
* Re: [PATCH 08/11] kbuild: create *.mod with full directory path and remove MODVERDIR
From: Masahiro Yamada @ 2019-07-11 5:30 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Linux Kbuild mailing list, Sam Ravnborg, open list:DOCUMENTATION,
Jonathan Corbet, Linux Kernel Mailing List, Michal Marek
In-Reply-To: <nycvar.YSQ.7.76.1907091332150.4190@knanqh.ubzr>
On Wed, Jul 10, 2019 at 2:37 AM Nicolas Pitre <nico@fluxnic.net> wrote:
>
> On Tue, 9 Jul 2019, Masahiro Yamada wrote:
>
> > --- a/scripts/adjust_autoksyms.sh
> > +++ b/scripts/adjust_autoksyms.sh
> > @@ -47,13 +47,10 @@ cat > "$new_ksyms_file" << EOT
> > */
> >
> > EOT
> > -[ "$(ls -A "$MODVERDIR")" ] &&
> > -for mod in "$MODVERDIR"/*.mod; do
> > - sed -n -e '3{s/ /\n/g;/^$/!p;}' "$mod"
> > -done | sort -u |
> > -while read sym; do
> > - echo "#define __KSYM_${sym} 1"
> > -done >> "$new_ksyms_file"
> > +sed 's/ko$/mod/' modules.order |
> > +xargs -r -n1 sed -n -e '3{s/ /\n/g;/^$/!p;}' |
> > +sort -u |
> > +sed -e 's/\(.*\)/#define __KSYM_\1 1/' >> "$new_ksyms_file"
>
> Did you consider the case when CONFIG_MODULES=y but no modules are
> selected?
I tested it, and worked.
Also -r to xargs is a GNU extension and there were some
> efforts to remove theur use in the past (no idea if this is still a
> concern).
It worked even without '-r', so I remove it in v2
Thanks.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v2 00/11] kbuild: create *.mod with directory path and remove MODVERDIR
From: Masahiro Yamada @ 2019-07-11 5:44 UTC (permalink / raw)
To: linux-kbuild
Cc: Sam Ravnborg, Nicolas Pitre, Masahiro Yamada, linux-scsi,
linux-doc, linux-kernel, Jonathan Corbet, Michal Marek,
Martin K. Petersen, James E.J. Bottomley
This series kills the long standing MODVERDIR.
Since MODVERDIR has a flat structure, it cannot avoid a race
condition when somebody introduces a module name conflict.
Kbuild now reads modules.order to get the list of all modules.
The post-processing/installation stages will be more robust
and simpler.
Masahiro Yamada (11):
kbuild: do not create empty modules.order in the prepare stage
kbuild: get rid of kernel/ prefix from in-tree modules.{order,builtin}
kbuild: remove duplication from modules.order in sub-directories
scsi: remove pointless $(MODVERDIR)/$(obj)/53c700.ver
kbuild: modinst: read modules.order instead of $(MODVERDIR)/*.mod
kbuild: modsign: read modules.order instead of $(MODVERDIR)/*.mod
kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod
kbuild: create *.mod with full directory path and remove MODVERDIR
kbuild: remove the first line of *.mod files
kbuild: remove 'prepare1' target
kbuild: split out *.mod out of {single,multi}-used-m rules
.gitignore | 1 +
Documentation/dontdiff | 1 +
Makefile | 36 ++++++++++--------------------------
drivers/scsi/Makefile | 2 +-
scripts/Makefile.build | 33 +++++++++++++++------------------
scripts/Makefile.modbuiltin | 2 +-
scripts/Makefile.modinst | 5 +----
scripts/Makefile.modpost | 17 +++++++++--------
scripts/Makefile.modsign | 3 +--
scripts/adjust_autoksyms.sh | 11 ++++-------
scripts/mod/sumversion.c | 23 ++++-------------------
scripts/modules-check.sh | 2 +-
scripts/package/mkspec | 2 +-
13 files changed, 50 insertions(+), 88 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH v2 08/11] kbuild: create *.mod with full directory path and remove MODVERDIR
From: Masahiro Yamada @ 2019-07-11 5:44 UTC (permalink / raw)
To: linux-kbuild
Cc: Sam Ravnborg, Nicolas Pitre, Masahiro Yamada, linux-doc,
Jonathan Corbet, linux-kernel, Michal Marek
In-Reply-To: <20190711054434.1177-1-yamada.masahiro@socionext.com>
While descending directories, Kbuild produces objects for modules,
but do not link final *.ko files; it is done in the modpost.
To keep track of modules, Kbuild creates a *.mod file in $(MODVERDIR)
for every module it is building. Some post-processing steps read the
necessary information from *.mod files. This avoids descending into
directories again. This mechanism was introduced in 2003 or so.
Later, commit 551559e13af1 ("kbuild: implement modules.order") added
modules.order. So, we can simply read it out to know all the modules
with directory paths. This is easier than parsing the first line of
*.mod files.
$(MODVERDIR) has a flat directory structure, that is, *.mod files
are named only with base names. This is based on the assumption that
the module name is unique across the tree. This assumption is really
fragile.
Stephen Rothwell reported a race condition caused by a module name
conflict:
https://lkml.org/lkml/2019/5/13/991
In parallel building, two different threads could write to the same
$(MODVERDIR)/*.mod simultaneously.
Non-unique module names are the source of all kind of troubles, hence
commit 3a48a91901c5 ("kbuild: check uniqueness of module names")
introduced a new checker script.
However, it is still fragile in the build system point of view because
this race happens before scripts/modules-check.sh is invoked. If it
happens again, the modpost will emit unclear error messages.
To fix this issue completely, create *.mod in the same directory as
*.ko so that two threads never attempt to write to the same file.
$(MODVERDIR) is no longer needed.
Since modules with directory paths are listed in modules.order, Kbuild
is still able to find *.mod files without additional descending.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
---
Changes in v2:
- Remove -r of xargs, which is a GNU extension
- Add '--' for extra safety
.gitignore | 1 +
Documentation/dontdiff | 1 +
Makefile | 20 +++-----------------
scripts/Makefile.build | 8 ++------
scripts/Makefile.modpost | 4 ++--
scripts/adjust_autoksyms.sh | 11 ++++-------
scripts/mod/sumversion.c | 16 +++-------------
scripts/package/mkspec | 2 +-
8 files changed, 17 insertions(+), 46 deletions(-)
diff --git a/.gitignore b/.gitignore
index 7587ef56b92d..8f5422cba6e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -30,6 +30,7 @@
*.lz4
*.lzma
*.lzo
+*.mod
*.mod.c
*.o
*.o.*
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 5eba889ea84d..9f4392876099 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -30,6 +30,7 @@
*.lzo
*.mo
*.moc
+*.mod
*.mod.c
*.o
*.o.*
diff --git a/Makefile b/Makefile
index b5e21d676ee2..4243b6daffcf 100644
--- a/Makefile
+++ b/Makefile
@@ -488,11 +488,6 @@ export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
export KBUILD_ARFLAGS
-# When compiling out-of-tree modules, put MODVERDIR in the module
-# tree rather than in the kernel tree. The kernel tree might
-# even be read-only.
-export MODVERDIR := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/).tmp_versions
-
# Files to ignore in find ... statements
export RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o \
@@ -1033,7 +1028,7 @@ vmlinux-deps := $(KBUILD_LDS) $(KBUILD_VMLINUX_OBJS) $(KBUILD_VMLINUX_LIBS)
# Recurse until adjust_autoksyms.sh is satisfied
PHONY += autoksyms_recursive
-autoksyms_recursive: $(vmlinux-deps)
+autoksyms_recursive: $(vmlinux-deps) modules.order
ifdef CONFIG_TRIM_UNUSED_KSYMS
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh \
"$(MAKE) -f $(srctree)/Makefile vmlinux"
@@ -1117,7 +1112,6 @@ endif
prepare1: prepare3 outputmakefile asm-generic $(version_h) $(autoksyms_h) \
include/generated/utsrelease.h
- $(cmd_crmodverdir)
archprepare: archheaders archscripts prepare1 scripts
@@ -1375,7 +1369,7 @@ endif # CONFIG_MODULES
# make distclean Remove editor backup files, patch leftover files and the like
# Directories & files removed with 'make clean'
-CLEAN_DIRS += $(MODVERDIR) include/ksym
+CLEAN_DIRS += include/ksym
CLEAN_FILES += modules.builtin.modinfo
# Directories & files removed with 'make mrproper'
@@ -1636,7 +1630,6 @@ PHONY += $(clean-dirs) clean
$(clean-dirs):
$(Q)$(MAKE) $(clean)=$(patsubst _clean_%,%,$@)
-clean: rm-dirs := $(MODVERDIR)
clean: rm-files := $(KBUILD_EXTMOD)/Module.symvers
PHONY += help
@@ -1650,8 +1643,6 @@ help:
@echo ''
PHONY += prepare
-prepare:
- $(cmd_crmodverdir)
endif # KBUILD_EXTMOD
clean: $(clean-dirs)
@@ -1662,7 +1653,7 @@ clean: $(clean-dirs)
-o -name '*.ko.*' \
-o -name '*.dtb' -o -name '*.dtb.S' -o -name '*.dt.yaml' \
-o -name '*.dwo' -o -name '*.lst' \
- -o -name '*.su' \
+ -o -name '*.su' -o -name '*.mod' \
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
-o -name '*.lex.c' -o -name '*.tab.[ch]' \
-o -name '*.asn1.[ch]' \
@@ -1791,11 +1782,6 @@ quiet_cmd_depmod = DEPMOD $(KERNELRELEASE)
cmd_depmod = $(CONFIG_SHELL) $(srctree)/scripts/depmod.sh $(DEPMOD) \
$(KERNELRELEASE)
-# Create temporary dir for module support files
-# clean it up only when building all modules
-cmd_crmodverdir = $(Q)mkdir -p $(MODVERDIR) \
- $(if $(KBUILD_MODULES),; rm -f $(MODVERDIR)/*)
-
# read saved command lines for existing targets
existing-targets := $(wildcard $(sort $(targets)))
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 98dede0b2ca8..9fb30633acd2 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -67,8 +67,6 @@ ifeq ($(CONFIG_MODULES)$(need-modorder),y1)
modorder-target := $(obj)/modules.order
endif
-# We keep a list of all modules in $(MODVERDIR)
-
__build: $(if $(KBUILD_BUILTIN),$(builtin-target) $(lib-target) $(extra-y)) \
$(if $(KBUILD_MODULES),$(obj-m) $(modorder-target)) \
$(subdir-ym) $(always)
@@ -278,13 +276,11 @@ $(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
-# Single-part modules are special since we need to mark them in $(MODVERDIR)
-
$(single-used-m): $(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) FORCE
$(call cmd,force_checksrc)
$(call if_changed_rule,cc_o_c)
@{ echo $(@:.o=.ko); echo $@; \
- $(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
+ $(cmd_undef_syms); } > $(patsubst %.o,%.mod,$@)
quiet_cmd_cc_lst_c = MKLST $@
cmd_cc_lst_c = $(CC) $(c_flags) -g -c -o $*.o $< && \
@@ -466,7 +462,7 @@ cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(filter %.o,$^) $(cmd_secanalysis
$(multi-used-m): FORCE
$(call if_changed,link_multi-m)
@{ echo $(@:.o=.ko); echo $(filter %.o,$^); \
- $(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
+ $(cmd_undef_syms); } > $(patsubst %.o,%.mod,$@)
$(call multi_depend, $(multi-used-m), .o, -objs -y -m)
targets += $(multi-used-m)
diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
index 2ab1694a7df3..3e229d4f4d72 100644
--- a/scripts/Makefile.modpost
+++ b/scripts/Makefile.modpost
@@ -6,8 +6,8 @@
# Stage one of module building created the following:
# a) The individual .o files used for the module
# b) A <module>.o file which is the .o files above linked together
-# c) A <module>.mod file in $(MODVERDIR)/, listing the name of the
-# the preliminary <module>.o file, plus all .o files
+# c) A <module>.mod file, listing the name of the preliminary <module>.o file,
+# plus all .o files
# d) modules.order, which lists all the modules
# Stage 2 is handled by this file and does the following
diff --git a/scripts/adjust_autoksyms.sh b/scripts/adjust_autoksyms.sh
index aab4e299d7a2..8b44bb80a451 100755
--- a/scripts/adjust_autoksyms.sh
+++ b/scripts/adjust_autoksyms.sh
@@ -47,13 +47,10 @@ cat > "$new_ksyms_file" << EOT
*/
EOT
-[ "$(ls -A "$MODVERDIR")" ] &&
-for mod in "$MODVERDIR"/*.mod; do
- sed -n -e '3{s/ /\n/g;/^$/!p;}' "$mod"
-done | sort -u |
-while read sym; do
- echo "#define __KSYM_${sym} 1"
-done >> "$new_ksyms_file"
+sed 's/ko$/mod/' modules.order |
+xargs -n1 sed -n -e '3{s/ /\n/g;/^$/!p;}' -- |
+sort -u |
+sed -e 's/\(.*\)/#define __KSYM_\1 1/' >> "$new_ksyms_file"
# Special case for modversions (see modpost.c)
if [ -n "$CONFIG_MODVERSIONS" ]; then
diff --git a/scripts/mod/sumversion.c b/scripts/mod/sumversion.c
index 0f6dcb4011a8..166f3fa247a9 100644
--- a/scripts/mod/sumversion.c
+++ b/scripts/mod/sumversion.c
@@ -396,21 +396,11 @@ void get_src_version(const char *modname, char sum[], unsigned sumlen)
unsigned long len;
struct md4_ctx md;
char *sources, *end, *fname;
- const char *basename;
char filelist[PATH_MAX + 1];
- char *modverdir = getenv("MODVERDIR");
- if (!modverdir)
- modverdir = ".";
-
- /* Source files for module are in .tmp_versions/modname.mod,
- after the first line. */
- if (strrchr(modname, '/'))
- basename = strrchr(modname, '/') + 1;
- else
- basename = modname;
- snprintf(filelist, sizeof(filelist), "%s/%.*s.mod", modverdir,
- (int) strlen(basename) - 2, basename);
+ /* objects for a module are listed in the second line of *.mod file. */
+ snprintf(filelist, sizeof(filelist), "%.*smod",
+ (int)strlen(modname) - 1, modname);
file = grab_file(filelist, &len);
if (!file)
diff --git a/scripts/package/mkspec b/scripts/package/mkspec
index 2d29df4a0a53..8640c278f1aa 100755
--- a/scripts/package/mkspec
+++ b/scripts/package/mkspec
@@ -29,7 +29,7 @@ fi
PROVIDES="$PROVIDES kernel-$KERNELRELEASE"
__KERNELRELEASE=$(echo $KERNELRELEASE | sed -e "s/-/_/g")
-EXCLUDES="$RCS_TAR_IGNORE --exclude=.tmp_versions --exclude=*vmlinux* \
+EXCLUDES="$RCS_TAR_IGNORE --exclude=*vmlinux* --exclude=*.mod \
--exclude=*.o --exclude=*.ko --exclude=*.cmd --exclude=Documentation \
--exclude=.config.old --exclude=.missing-syscalls.d --exclude=*.s"
--
2.17.1
^ permalink raw reply related
* Re: [v1 0/5] allow to reserve memory for normal kexec kernel
From: Vladimir Murzin @ 2019-07-11 8:12 UTC (permalink / raw)
To: Pavel Tatashin, James Morse
Cc: Sasha Levin, Jonathan Corbet, Catalin Marinas, Bhupesh Sharma,
Linux Doc Mailing List, kexec mailing list,
Linux Kernel Mailing List, James Morris, Eric Biederman, will,
linux-arm-kernel
In-Reply-To: <CA+CK2bBWis8TgyOmDhVgLYrOU95Za-UhSGSB3ufsjiNDt-Zd_w@mail.gmail.com>
Hi,
On 7/10/19 4:56 PM, Pavel Tatashin wrote:
> On Wed, Jul 10, 2019 at 11:19 AM James Morse <james.morse@arm.com> wrote:
>>
>> Hi Pasha,
>>
>> On 09/07/2019 14:07, Pavel Tatashin wrote:
>>>>> Enabling MMU and D-Cache for relocation would essentially require the
>>>>> same changes in kernel. Could you please share exactly why these were
>>>>> not accepted upstream into kexec-tools?
>>>>
>>>> Because '--no-checks' is a much simpler alternative.
>>>>
>>>> More of the discussion:
>>>> https://lore.kernel.org/linux-arm-kernel/5599813d-f83c-d154-287a-c131c48292ca@arm.com/
>>>>
>>>> While you can make purgatory a fully-fledged operating system, it doesn't really need to
>>>> do anything on arm64. Errata-workarounds alone are a reason not do start down this path.
>>>
>>> Thank you James. I will summaries the information gathered from the
>>> yesterday's/today's discussion and add it to the cover letter together
>>> with ARM64 tag. I think, the patch series makes sense for ARM64 only,
>>> unless there are other platforms that disable caching/MMU during
>>> relocation.
>>
>> I'd prefer not to reserve additional memory for regular kexec just to avoid the relocation.
>> If the kernel's relocation work is so painful we can investigate doing it while the MMU is
>> enabled. If you can compare regular-kexec with kexec_file_load() you eliminate the
>> purgatory part of the work.
>
> Relocation time is exactly the same for regular-kexec and
> kexec_file_load(). So, the relocation is indeed painful for our case.
> I am working on adding MMU enabled kernel relocation.
Out of curiosity, does enabling only I-cache make a difference? IIRC, it doesn't
require setting MMU, in contrast to D-cache.
Cheers
Vladimir
>
> Pasha
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* Re: [PATCH v5 1/1] sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices
From: Peter Zijlstra @ 2019-07-11 9:51 UTC (permalink / raw)
To: bsegall
Cc: Dave Chiluk, Pqhil Auld, Peter Oskolkov, Ingo Molnar, cgroups,
linux-kernel, Brendan Gregg, Kyle Anderson, Gabriel Munos,
John Hammond, Cong Wang, Jonathan Corbet, linux-doc, Paul Turner
In-Reply-To: <xm26lfxhwlxr.fsf@bsegall-linux.svl.corp.google.com>
FWIW, good to see progress, still waiting for you guys to agree :-)
On Mon, Jul 01, 2019 at 01:15:44PM -0700, bsegall@google.com wrote:
> - Taking up-to-every rq->lock is bad and expensive and 5ms may be too
> short a delay for this. I haven't tried microbenchmarks on the cost of
> this vs min_cfs_rq_runtime = 0 vs baseline.
Yes, that's tricky, SGI/HPE have definite ideas about that.
> @@ -4781,12 +4790,41 @@ static __always_inline void return_cfs_rq_runtime(struct cfs_rq *cfs_rq)
> */
> static void do_sched_cfs_slack_timer(struct cfs_bandwidth *cfs_b)
> {
> - u64 runtime = 0, slice = sched_cfs_bandwidth_slice();
> + u64 runtime = 0;
> unsigned long flags;
> u64 expires;
> + struct cfs_rq *cfs_rq, *temp;
> + LIST_HEAD(temp_head);
> +
> + local_irq_save(flags);
> +
> + raw_spin_lock(&cfs_b->lock);
> + cfs_b->slack_started = false;
> + list_splice_init(&cfs_b->slack_cfs_rq, &temp_head);
> + raw_spin_unlock(&cfs_b->lock);
> +
> +
> + /* Gather all left over runtime from all rqs */
> + list_for_each_entry_safe(cfs_rq, temp, &temp_head, slack_list) {
> + struct rq *rq = rq_of(cfs_rq);
> + struct rq_flags rf;
> +
> + rq_lock(rq, &rf);
> +
> + raw_spin_lock(&cfs_b->lock);
> + list_del_init(&cfs_rq->slack_list);
> + if (!cfs_rq->nr_running && cfs_rq->runtime_remaining > 0 &&
> + cfs_rq->runtime_expires == cfs_b->runtime_expires) {
> + cfs_b->runtime += cfs_rq->runtime_remaining;
> + cfs_rq->runtime_remaining = 0;
> + }
> + raw_spin_unlock(&cfs_b->lock);
> +
> + rq_unlock(rq, &rf);
> + }
But worse still, you take possibly every rq->lock without ever
re-enabling IRQs.
>
> /* confirm we're still not at a refresh boundary */
> - raw_spin_lock_irqsave(&cfs_b->lock, flags);
> + raw_spin_lock(&cfs_b->lock);
> cfs_b->slack_started = false;
> if (cfs_b->distribute_running) {
> raw_spin_unlock_irqrestore(&cfs_b->lock, flags);
^ permalink raw reply
* Re: [v1 0/5] allow to reserve memory for normal kexec kernel
From: Pavel Tatashin @ 2019-07-11 12:26 UTC (permalink / raw)
To: Vladimir Murzin
Cc: James Morse, Sasha Levin, Jonathan Corbet, Catalin Marinas,
Bhupesh Sharma, Linux Doc Mailing List, kexec mailing list,
Linux Kernel Mailing List, James Morris, Eric Biederman, will,
linux-arm-kernel
In-Reply-To: <93f99d54-9fe4-a191-4877-080ad78322bb@arm.com>
On Thu, Jul 11, 2019 at 4:12 AM Vladimir Murzin <vladimir.murzin@arm.com> wrote:
>
> Hi,
>
> On 7/10/19 4:56 PM, Pavel Tatashin wrote:
> > On Wed, Jul 10, 2019 at 11:19 AM James Morse <james.morse@arm.com> wrote:
> >>
> >> Hi Pasha,
> >>
> >> On 09/07/2019 14:07, Pavel Tatashin wrote:
> >>>>> Enabling MMU and D-Cache for relocation would essentially require the
> >>>>> same changes in kernel. Could you please share exactly why these were
> >>>>> not accepted upstream into kexec-tools?
> >>>>
> >>>> Because '--no-checks' is a much simpler alternative.
> >>>>
> >>>> More of the discussion:
> >>>> https://lore.kernel.org/linux-arm-kernel/5599813d-f83c-d154-287a-c131c48292ca@arm.com/
> >>>>
> >>>> While you can make purgatory a fully-fledged operating system, it doesn't really need to
> >>>> do anything on arm64. Errata-workarounds alone are a reason not do start down this path.
> >>>
> >>> Thank you James. I will summaries the information gathered from the
> >>> yesterday's/today's discussion and add it to the cover letter together
> >>> with ARM64 tag. I think, the patch series makes sense for ARM64 only,
> >>> unless there are other platforms that disable caching/MMU during
> >>> relocation.
> >>
> >> I'd prefer not to reserve additional memory for regular kexec just to avoid the relocation.
> >> If the kernel's relocation work is so painful we can investigate doing it while the MMU is
> >> enabled. If you can compare regular-kexec with kexec_file_load() you eliminate the
> >> purgatory part of the work.
> >
> > Relocation time is exactly the same for regular-kexec and
> > kexec_file_load(). So, the relocation is indeed painful for our case.
> > I am working on adding MMU enabled kernel relocation.
>
> Out of curiosity, does enabling only I-cache make a difference? IIRC, it doesn't
> require setting MMU, in contrast to D-cache.
Resend:
Thank you for suggestion. I have actually experimented with enabling
caches without MMU. Did not see a difference.
Thank you,
Pasha
>
> Cheers
> Vladimir
>
> >
> > Pasha
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>
^ permalink raw reply
* Re: [Patch V4] Documentation: coresight: covert txt to rst
From: Mathieu Poirier @ 2019-07-11 16:18 UTC (permalink / raw)
To: Phong Tran
Cc: Jon Corbet, Leo Yan, mchehab, linux-arm-kernel,
open list:DOCUMENTATION, linux-kernel-mentees,
Linux Kernel Mailing List, skhan, Suzuki K. Poulose
In-Reply-To: <20190710150133.13992-1-tranmanphong@gmail.com>
On Wed, 10 Jul 2019 at 09:01, Phong Tran <tranmanphong@gmail.com> wrote:
>
> as doc-guide of kernel documentation, use Sphinx tool to
> generate the html/pdf... files.
>
> This changes the plan text txt to rst format.
>
I agree with Mauro - although the changelong has already been improved
it is still below the minimum requirements.
> Signed-off-by: Phong Tran <tranmanphong@gmail.com>
As for the content of the patch:
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> ---
> ChangeLog:
> V2: review points from Mathieu, Jonathan
> * Add coresight-cpu-debug
> * Update MAINTAINERS file
> * Avoid use markup as much as posible
> V3: review points from Mauro
> * add the colon author, date
> * change to use ```` in the struct
> * add line for the acronyms
> V4:
> * Rebase on linux-next tree
> ---
> ...sight-cpu-debug.txt => coresight-cpu-debug.rst} | 67 ++--
> .../trace/{coresight.txt => coresight.rst} | 372 +++++++++++----------
> Documentation/trace/index.rst | 2 +
> MAINTAINERS | 4 +-
> 4 files changed, 234 insertions(+), 211 deletions(-)
> rename Documentation/trace/{coresight-cpu-debug.txt => coresight-cpu-debug.rst} (84%)
> rename Documentation/trace/{coresight.txt => coresight.rst} (56%)
>
> diff --git a/Documentation/trace/coresight-cpu-debug.txt b/Documentation/trace/coresight-cpu-debug.rst
> similarity index 84%
> rename from Documentation/trace/coresight-cpu-debug.txt
> rename to Documentation/trace/coresight-cpu-debug.rst
> index 1a660a39e3c0..993dd294b81b 100644
> --- a/Documentation/trace/coresight-cpu-debug.txt
> +++ b/Documentation/trace/coresight-cpu-debug.rst
> @@ -1,8 +1,9 @@
> - Coresight CPU Debug Module
> - ==========================
> +==========================
> +Coresight CPU Debug Module
> +==========================
>
> - Author: Leo Yan <leo.yan@linaro.org>
> - Date: April 5th, 2017
> + :Author: Leo Yan <leo.yan@linaro.org>
> + :Date: April 5th, 2017
>
> Introduction
> ------------
> @@ -69,6 +70,7 @@ Before accessing debug registers, we should ensure the clock and power domain
> have been enabled properly. In ARMv8-a ARM (ARM DDI 0487A.k) chapter 'H9.1
> Debug registers', the debug registers are spread into two domains: the debug
> domain and the CPU domain.
> +::
>
> +---------------+
> | |
> @@ -125,18 +127,21 @@ If you want to enable debugging functionality at boot time, you can add
> "coresight_cpu_debug.enable=1" to the kernel command line parameter.
>
> The driver also can work as module, so can enable the debugging when insmod
> -module:
> -# insmod coresight_cpu_debug.ko debug=1
> +module::
> +
> + # insmod coresight_cpu_debug.ko debug=1
>
> When boot time or insmod module you have not enabled the debugging, the driver
> uses the debugfs file system to provide a knob to dynamically enable or disable
> debugging:
>
> -To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable:
> -# echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable
> +To enable it, write a '1' into /sys/kernel/debug/coresight_cpu_debug/enable::
> +
> + # echo 1 > /sys/kernel/debug/coresight_cpu_debug/enable
> +
> +To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable::
>
> -To disable it, write a '0' into /sys/kernel/debug/coresight_cpu_debug/enable:
> -# echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable
> + # echo 0 > /sys/kernel/debug/coresight_cpu_debug/enable
>
> As explained in chapter "Clock and power domain", if you are working on one
> platform which has idle states to power off debug logic and the power
> @@ -154,34 +159,34 @@ subsystem, more specifically by using the "/dev/cpu_dma_latency"
> interface (see Documentation/power/pm_qos_interface.rst for more
> details). As specified in the PM QoS documentation the requested
> parameter will stay in effect until the file descriptor is released.
> -For example:
> +For example::
>
> -# exec 3<> /dev/cpu_dma_latency; echo 0 >&3
> -...
> -Do some work...
> -...
> -# exec 3<>-
> + # exec 3<> /dev/cpu_dma_latency; echo 0 >&3
> + ...
> + Do some work...
> + ...
> + # exec 3<>-
>
> The same can also be done from an application program.
>
> Disable specific CPU's specific idle state from cpuidle sysfs (see
> -Documentation/admin-guide/pm/cpuidle.rst):
> -# echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
> +Documentation/admin-guide/pm/cpuidle.rst)::
>
> + # echo 1 > /sys/devices/system/cpu/cpu$cpu/cpuidle/state$state/disable
>
> Output format
> -------------
>
> -Here is an example of the debugging output format:
> -
> -ARM external debug module:
> -coresight-cpu-debug 850000.debug: CPU[0]:
> -coresight-cpu-debug 850000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
> -coresight-cpu-debug 850000.debug: EDPCSR: handle_IPI+0x174/0x1d8
> -coresight-cpu-debug 850000.debug: EDCIDSR: 00000000
> -coresight-cpu-debug 850000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
> -coresight-cpu-debug 852000.debug: CPU[1]:
> -coresight-cpu-debug 852000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
> -coresight-cpu-debug 852000.debug: EDPCSR: debug_notifier_call+0x23c/0x358
> -coresight-cpu-debug 852000.debug: EDCIDSR: 00000000
> -coresight-cpu-debug 852000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
> +Here is an example of the debugging output format::
> +
> + ARM external debug module:
> + coresight-cpu-debug 850000.debug: CPU[0]:
> + coresight-cpu-debug 850000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
> + coresight-cpu-debug 850000.debug: EDPCSR: handle_IPI+0x174/0x1d8
> + coresight-cpu-debug 850000.debug: EDCIDSR: 00000000
> + coresight-cpu-debug 850000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
> + coresight-cpu-debug 852000.debug: CPU[1]:
> + coresight-cpu-debug 852000.debug: EDPRSR: 00000001 (Power:On DLK:Unlock)
> + coresight-cpu-debug 852000.debug: EDPCSR: debug_notifier_call+0x23c/0x358
> + coresight-cpu-debug 852000.debug: EDCIDSR: 00000000
> + coresight-cpu-debug 852000.debug: EDVIDSR: 90000000 (State:Non-secure Mode:EL1/0 Width:64bits VMID:0)
> diff --git a/Documentation/trace/coresight.txt b/Documentation/trace/coresight.rst
> similarity index 56%
> rename from Documentation/trace/coresight.txt
> rename to Documentation/trace/coresight.rst
> index b027d61b27a6..72f4b7ef1bad 100644
> --- a/Documentation/trace/coresight.txt
> +++ b/Documentation/trace/coresight.rst
> @@ -1,8 +1,9 @@
> - Coresight - HW Assisted Tracing on ARM
> - ======================================
> +======================================
> +Coresight - HW Assisted Tracing on ARM
> +======================================
>
> - Author: Mathieu Poirier <mathieu.poirier@linaro.org>
> - Date: September 11th, 2014
> + :Author: Mathieu Poirier <mathieu.poirier@linaro.org>
> + :Date: September 11th, 2014
>
> Introduction
> ------------
> @@ -26,7 +27,7 @@ implementation, either storing the compressed stream in a memory buffer or
> creating an interface to the outside world where data can be transferred to a
> host without fear of filling up the onboard coresight memory buffer.
>
> -At typical coresight system would look like this:
> +At typical coresight system would look like this::
>
> *****************************************************************
> **************************** AMBA AXI ****************************===||
> @@ -95,15 +96,24 @@ Acronyms and Classification
>
> Acronyms:
>
> -PTM: Program Trace Macrocell
> -ETM: Embedded Trace Macrocell
> -STM: System trace Macrocell
> -ETB: Embedded Trace Buffer
> -ITM: Instrumentation Trace Macrocell
> -TPIU: Trace Port Interface Unit
> -TMC-ETR: Trace Memory Controller, configured as Embedded Trace Router
> -TMC-ETF: Trace Memory Controller, configured as Embedded Trace FIFO
> -CTI: Cross Trigger Interface
> +PTM:
> + Program Trace Macrocell
> +ETM:
> + Embedded Trace Macrocell
> +STM:
> + System trace Macrocell
> +ETB:
> + Embedded Trace Buffer
> +ITM:
> + Instrumentation Trace Macrocell
> +TPIU:
> + Trace Port Interface Unit
> +TMC-ETR:
> + Trace Memory Controller, configured as Embedded Trace Router
> +TMC-ETF:
> + Trace Memory Controller, configured as Embedded Trace FIFO
> +CTI:
> + Cross Trigger Interface
>
> Classification:
>
> @@ -118,7 +128,7 @@ Misc:
>
>
> Device Tree Bindings
> -----------------------
> +--------------------
>
> See Documentation/devicetree/bindings/arm/coresight.txt for details.
>
> @@ -133,79 +143,79 @@ The coresight framework provides a central point to represent, configure and
> manage coresight devices on a platform. Any coresight compliant device can
> register with the framework for as long as they use the right APIs:
>
> -struct coresight_device *coresight_register(struct coresight_desc *desc);
> -void coresight_unregister(struct coresight_device *csdev);
> +.. c:function:: struct coresight_device *coresight_register(struct coresight_desc *desc);
> +.. c:function:: void coresight_unregister(struct coresight_device *csdev);
>
> -The registering function is taking a "struct coresight_device *csdev" and
> -register the device with the core framework. The unregister function takes
> -a reference to a "struct coresight_device", obtained at registration time.
> +The registering function is taking a ``struct coresight_desc *desc`` and
> +register the device with the core framework. The unregister function takes
> +a reference to a ``struct coresight_device *csdev`` obtained at registration time.
>
> If everything goes well during the registration process the new devices will
> -show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
> +show up under /sys/bus/coresight/devices, as showns here for a TC2 platform::
>
> -root:~# ls /sys/bus/coresight/devices/
> -replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
> -20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> -root:~#
> + root:~# ls /sys/bus/coresight/devices/
> + replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
> + 20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> + root:~#
>
> -The functions take a "struct coresight_device", which looks like this:
> +The functions take a ``struct coresight_device``, which looks like this::
>
> -struct coresight_desc {
> - enum coresight_dev_type type;
> - struct coresight_dev_subtype subtype;
> - const struct coresight_ops *ops;
> - struct coresight_platform_data *pdata;
> - struct device *dev;
> - const struct attribute_group **groups;
> -};
> + struct coresight_desc {
> + enum coresight_dev_type type;
> + struct coresight_dev_subtype subtype;
> + const struct coresight_ops *ops;
> + struct coresight_platform_data *pdata;
> + struct device *dev;
> + const struct attribute_group **groups;
> + };
>
>
> The "coresight_dev_type" identifies what the device is, i.e, source link or
> sink while the "coresight_dev_subtype" will characterise that type further.
>
> -The "struct coresight_ops" is mandatory and will tell the framework how to
> +The ``struct coresight_ops`` is mandatory and will tell the framework how to
> perform base operations related to the components, each component having
> -a different set of requirement. For that "struct coresight_ops_sink",
> -"struct coresight_ops_link" and "struct coresight_ops_source" have been
> +a different set of requirement. For that ``struct coresight_ops_sink``,
> +``struct coresight_ops_link`` and ``struct coresight_ops_source`` have been
> provided.
>
> -The next field, "struct coresight_platform_data *pdata" is acquired by calling
> -"of_get_coresight_platform_data()", as part of the driver's _probe routine and
> -"struct device *dev" gets the device reference embedded in the "amba_device":
> +The next field ``struct coresight_platform_data *pdata`` is acquired by calling
> +``of_get_coresight_platform_data()``, as part of the driver's _probe routine and
> +``struct device *dev`` gets the device reference embedded in the ``amba_device``::
>
> -static int etm_probe(struct amba_device *adev, const struct amba_id *id)
> -{
> - ...
> - ...
> - drvdata->dev = &adev->dev;
> - ...
> -}
> + static int etm_probe(struct amba_device *adev, const struct amba_id *id)
> + {
> + ...
> + ...
> + drvdata->dev = &adev->dev;
> + ...
> + }
>
> Specific class of device (source, link, or sink) have generic operations
> -that can be performed on them (see "struct coresight_ops"). The
> -"**groups" is a list of sysfs entries pertaining to operations
> +that can be performed on them (see ``struct coresight_ops``). The ``**groups``
> +is a list of sysfs entries pertaining to operations
> specific to that component only. "Implementation defined" customisations are
> expected to be accessed and controlled using those entries.
>
> -
> Device Naming scheme
> -------------------------
> +--------------------
> +
> The devices that appear on the "coresight" bus were named the same as their
> parent devices, i.e, the real devices that appears on AMBA bus or the platform bus.
> Thus the names were based on the Linux Open Firmware layer naming convention,
> which follows the base physical address of the device followed by the device
> -type. e.g:
> +type. e.g::
>
> -root:~# ls /sys/bus/coresight/devices/
> - 20010000.etf 20040000.funnel 20100000.stm 22040000.etm
> - 22140000.etm 230c0000.funnel 23240000.etm 20030000.tpiu
> - 20070000.etr 20120000.replicator 220c0000.funnel
> - 23040000.etm 23140000.etm 23340000.etm
> + root:~# ls /sys/bus/coresight/devices/
> + 20010000.etf 20040000.funnel 20100000.stm 22040000.etm
> + 22140000.etm 230c0000.funnel 23240000.etm 20030000.tpiu
> + 20070000.etr 20120000.replicator 220c0000.funnel
> + 23040000.etm 23140000.etm 23340000.etm
>
> However, with the introduction of ACPI support, the names of the real
> devices are a bit cryptic and non-obvious. Thus, a new naming scheme was
> introduced to use more generic names based on the type of the device. The
> -following rules apply:
> +following rules apply::
>
> 1) Devices that are bound to CPUs, are named based on the CPU logical
> number.
> @@ -220,11 +230,11 @@ following rules apply:
>
> e.g, tmc_etf0, tmc_etr0, funnel0, funnel1
>
> -Thus, with the new scheme the devices could appear as :
> +Thus, with the new scheme the devices could appear as ::
>
> -root:~# ls /sys/bus/coresight/devices/
> - etm0 etm1 etm2 etm3 etm4 etm5 funnel0
> - funnel1 funnel2 replicator0 stm0 tmc_etf0 tmc_etr0 tpiu0
> + root:~# ls /sys/bus/coresight/devices/
> + etm0 etm1 etm2 etm3 etm4 etm5 funnel0
> + funnel1 funnel2 replicator0 stm0 tmc_etf0 tmc_etr0 tpiu0
>
> Some of the examples below might refer to old naming scheme and some
> to the newer scheme, to give a confirmation that what you see on your
> @@ -234,9 +244,12 @@ the system under specified locations.
> How to use the tracer modules
> -----------------------------
>
> -There are two ways to use the Coresight framework: 1) using the perf cmd line
> -tools and 2) interacting directly with the Coresight devices using the sysFS
> -interface. Preference is given to the former as using the sysFS interface
> +There are two ways to use the Coresight framework:
> +
> +1. using the perf cmd line tools.
> +2. interacting directly with the Coresight devices using the sysFS interface.
> +
> +Preference is given to the former as using the sysFS interface
> requires a deep understanding of the Coresight HW. The following sections
> provide details on using both methods.
>
> @@ -245,107 +258,107 @@ provide details on using both methods.
> Before trace collection can start, a coresight sink needs to be identified.
> There is no limit on the amount of sinks (nor sources) that can be enabled at
> any given moment. As a generic operation, all device pertaining to the sink
> -class will have an "active" entry in sysfs:
> -
> -root:/sys/bus/coresight/devices# ls
> -replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
> -20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> -root:/sys/bus/coresight/devices# ls 20010000.etb
> -enable_sink status trigger_cntr
> -root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
> -root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
> -1
> -root:/sys/bus/coresight/devices#
> +class will have an "active" entry in sysfs::
> +
> + root:/sys/bus/coresight/devices# ls
> + replicator 20030000.tpiu 2201c000.ptm 2203c000.etm 2203e000.etm
> + 20010000.etb 20040000.funnel 2201d000.ptm 2203d000.etm
> + root:/sys/bus/coresight/devices# ls 20010000.etb
> + enable_sink status trigger_cntr
> + root:/sys/bus/coresight/devices# echo 1 > 20010000.etb/enable_sink
> + root:/sys/bus/coresight/devices# cat 20010000.etb/enable_sink
> + 1
> + root:/sys/bus/coresight/devices#
>
> At boot time the current etm3x driver will configure the first address
> comparator with "_stext" and "_etext", essentially tracing any instruction
> that falls within that range. As such "enabling" a source will immediately
> -trigger a trace capture:
> -
> -root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
> -root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
> -1
> -root:/sys/bus/coresight/devices# cat 20010000.etb/status
> -Depth: 0x2000
> -Status: 0x1
> -RAM read ptr: 0x0
> -RAM wrt ptr: 0x19d3 <----- The write pointer is moving
> -Trigger cnt: 0x0
> -Control: 0x1
> -Flush status: 0x0
> -Flush ctrl: 0x2001
> -root:/sys/bus/coresight/devices#
> -
> -Trace collection is stopped the same way:
> -
> -root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source
> -root:/sys/bus/coresight/devices#
> -
> -The content of the ETB buffer can be harvested directly from /dev:
> -
> -root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \
> -of=~/cstrace.bin
> -
> -64+0 records in
> -64+0 records out
> -32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s
> -root:/sys/bus/coresight/devices#
> +trigger a trace capture::
> +
> + root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
> + root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
> + 1
> + root:/sys/bus/coresight/devices# cat 20010000.etb/status
> + Depth: 0x2000
> + Status: 0x1
> + RAM read ptr: 0x0
> + RAM wrt ptr: 0x19d3 <----- The write pointer is moving
> + Trigger cnt: 0x0
> + Control: 0x1
> + Flush status: 0x0
> + Flush ctrl: 0x2001
> + root:/sys/bus/coresight/devices#
> +
> +Trace collection is stopped the same way::
> +
> + root:/sys/bus/coresight/devices# echo 0 > 2201c000.ptm/enable_source
> + root:/sys/bus/coresight/devices#
> +
> +The content of the ETB buffer can be harvested directly from /dev::
> +
> + root:/sys/bus/coresight/devices# dd if=/dev/20010000.etb \
> + of=~/cstrace.bin
> + 64+0 records in
> + 64+0 records out
> + 32768 bytes (33 kB) copied, 0.00125258 s, 26.2 MB/s
> + root:/sys/bus/coresight/devices#
>
> The file cstrace.bin can be decompressed using "ptm2human", DS-5 or Trace32.
>
> Following is a DS-5 output of an experimental loop that increments a variable up
> to a certain value. The example is simple and yet provides a glimpse of the
> wealth of possibilities that coresight provides.
> -
> -Info Tracing enabled
> -Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr}
> -Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc
> -Instruction 0 0x8026B544 E3A03000 false MOV r3,#0
> -Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Timestamp Timestamp: 17106715833
> -Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> -Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> -Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> -Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> -Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> -Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1
> -Instruction 0 0x8026B564 E1A0100D false MOV r1,sp
> -Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0
> -Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f
> -Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4]
> -Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368
> -Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc]
> -Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0]
> -Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4
> -Info Tracing enabled
> -Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc
> -Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
> -Timestamp Timestamp: 17107041535
> +::
> +
> + Info Tracing enabled
> + Instruction 106378866 0x8026B53C E52DE004 false PUSH {lr}
> + Instruction 0 0x8026B540 E24DD00C false SUB sp,sp,#0xc
> + Instruction 0 0x8026B544 E3A03000 false MOV r3,#0
> + Instruction 0 0x8026B548 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Timestamp Timestamp: 17106715833
> + Instruction 319 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Instruction 9 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Instruction 7 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Instruction 10 0x8026B54C E59D3004 false LDR r3,[sp,#4]
> + Instruction 0 0x8026B550 E3530004 false CMP r3,#4
> + Instruction 0 0x8026B554 E2833001 false ADD r3,r3,#1
> + Instruction 0 0x8026B558 E58D3004 false STR r3,[sp,#4]
> + Instruction 0 0x8026B55C DAFFFFFA true BLE {pc}-0x10 ; 0x8026b54c
> + Instruction 6 0x8026B560 EE1D3F30 false MRC p15,#0x0,r3,c13,c0,#1
> + Instruction 0 0x8026B564 E1A0100D false MOV r1,sp
> + Instruction 0 0x8026B568 E3C12D7F false BIC r2,r1,#0x1fc0
> + Instruction 0 0x8026B56C E3C2203F false BIC r2,r2,#0x3f
> + Instruction 0 0x8026B570 E59D1004 false LDR r1,[sp,#4]
> + Instruction 0 0x8026B574 E59F0010 false LDR r0,[pc,#16] ; [0x8026B58C] = 0x80550368
> + Instruction 0 0x8026B578 E592200C false LDR r2,[r2,#0xc]
> + Instruction 0 0x8026B57C E59221D0 false LDR r2,[r2,#0x1d0]
> + Instruction 0 0x8026B580 EB07A4CF true BL {pc}+0x1e9344 ; 0x804548c4
> + Info Tracing enabled
> + Instruction 13570831 0x8026B584 E28DD00C false ADD sp,sp,#0xc
> + Instruction 0 0x8026B588 E8BD8000 true LDM sp!,{pc}
> + Timestamp Timestamp: 17107041535
>
> 2) Using perf framework:
>
> @@ -370,19 +383,18 @@ A Coresight PMU works the same way as any other PMU, i.e the name of the PMU is
> listed along with configuration options within forward slashes '/'. Since a
> Coresight system will typically have more than one sink, the name of the sink to
> work with needs to be specified as an event option.
> -On newer kernels the available sinks are listed in sysFS under:
> -($SYSFS)/bus/event_source/devices/cs_etm/sinks/
> +On newer kernels the available sinks are listed in sysFS under
> +($SYSFS)/bus/event_source/devices/cs_etm/sinks/::
>
> root@localhost:/sys/bus/event_source/devices/cs_etm/sinks# ls
> tmc_etf0 tmc_etr0 tpiu0
>
> On older kernels, this may need to be found from the list of coresight devices,
> -available under ($SYSFS)/bus/coresight/devices/:
> +available under ($SYSFS)/bus/coresight/devices/::
>
> root:~# ls /sys/bus/coresight/devices/
> etm0 etm1 etm2 etm3 etm4 etm5 funnel0
> funnel1 funnel2 replicator0 stm0 tmc_etf0 tmc_etr0 tpiu0
> -
> root@linaro-nano:~# perf record -e cs_etm/@tmc_etr0/u --per-thread program
>
> As mentioned above in section "Device Naming scheme", the names of the devices could
> @@ -395,14 +407,14 @@ to use for the trace session.
>
> More information on the above and other example on how to use Coresight with
> the perf tools can be found in the "HOWTO.md" file of the openCSD gitHub
> -repository [3].
> +repository [#third]_.
>
> 2.1) AutoFDO analysis using the perf tools:
>
> perf can be used to record and analyze trace of programs.
>
> Execution can be recorded using 'perf record' with the cs_etm event,
> -specifying the name of the sink to record to, e.g:
> +specifying the name of the sink to record to, e.g::
>
> perf record -e cs_etm/@tmc_etr0/u --per-thread
>
> @@ -421,12 +433,14 @@ Generating coverage files for Feedback Directed Optimization: AutoFDO
>
> 'perf inject' accepts the --itrace option in which case tracing data is
> removed and replaced with the synthesized events. e.g.
> +::
>
> perf inject --itrace --strip -i perf.data -o perf.data.new
>
> Below is an example of using ARM ETM for autoFDO. It requires autofdo
> (https://github.com/google/autofdo) and gcc version 5. The bubble
> sort example is from the AutoFDO tutorial (https://gcc.gnu.org/wiki/AutoFDO/Tutorial).
> +::
>
> $ gcc-5 -O3 sort.c -o sort
> $ taskset -c 2 ./sort
> @@ -455,28 +469,30 @@ difference is that clients are driving the trace capture rather
> than the program flow through the code.
>
> As with any other CoreSight component, specifics about the STM tracer can be
> -found in sysfs with more information on each entry being found in [1]:
> +found in sysfs with more information on each entry being found in [#first]_::
>
> -root@genericarmv8:~# ls /sys/bus/coresight/devices/stm0
> -enable_source hwevent_select port_enable subsystem uevent
> -hwevent_enable mgmt port_select traceid
> -root@genericarmv8:~#
> + root@genericarmv8:~# ls /sys/bus/coresight/devices/stm0
> + enable_source hwevent_select port_enable subsystem uevent
> + hwevent_enable mgmt port_select traceid
> + root@genericarmv8:~#
>
> Like any other source a sink needs to be identified and the STM enabled before
> -being used:
> +being used::
>
> -root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
> -root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/stm0/enable_source
> + root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/tmc_etf0/enable_sink
> + root@genericarmv8:~# echo 1 > /sys/bus/coresight/devices/stm0/enable_source
>
> From there user space applications can request and use channels using the devfs
> -interface provided for that purpose by the generic STM API:
> +interface provided for that purpose by the generic STM API::
> +
> + root@genericarmv8:~# ls -l /dev/stm0
> + crw------- 1 root root 10, 61 Jan 3 18:11 /dev/stm0
> + root@genericarmv8:~#
> +
> +Details on how to use the generic STM API can be found here [#second]_.
>
> -root@genericarmv8:~# ls -l /dev/stm0
> -crw------- 1 root root 10, 61 Jan 3 18:11 /dev/stm0
> -root@genericarmv8:~#
> +.. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
>
> -Details on how to use the generic STM API can be found here [2].
> +.. [#second] Documentation/trace/stm.rst
>
> -[1]. Documentation/ABI/testing/sysfs-bus-coresight-devices-stm
> -[2]. Documentation/trace/stm.rst
> -[3]. https://github.com/Linaro/perf-opencsd
> +.. [#third] https://github.com/Linaro/perf-opencsd
> diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst
> index 6b4107cf4b98..b7891cb1ab4d 100644
> --- a/Documentation/trace/index.rst
> +++ b/Documentation/trace/index.rst
> @@ -23,3 +23,5 @@ Linux Tracing Technologies
> intel_th
> stm
> sys-t
> + coresight
> + coresight-cpu-debug
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 661def85619c..eb03e5966f11 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1582,8 +1582,8 @@ R: Suzuki K Poulose <suzuki.poulose@arm.com>
> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> F: drivers/hwtracing/coresight/*
> -F: Documentation/trace/coresight.txt
> -F: Documentation/trace/coresight-cpu-debug.txt
> +F: Documentation/trace/coresight.rst
> +F: Documentation/trace/coresight-cpu-debug.rst
> F: Documentation/devicetree/bindings/arm/coresight.txt
> F: Documentation/devicetree/bindings/arm/coresight-cpu-debug.txt
> F: Documentation/ABI/testing/sysfs-bus-coresight-devices-*
> --
> 2.11.0
>
^ permalink raw reply
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