When the kernel is running at EL2, the PID is stored in CONTEXTIDR_EL2.
So, tracing CONTEXTIDR_EL1 doesn't give us the pid of the process.
Thus we should trace the VMID with VMIDOPT set to trace CONTEXTIDR_EL2
instead of CONTEXTIDR_EL1. Given that we have an existing config
option "contextid" and this will be useful for tracing virtual machines
(when we get to support virtualization).
So instead, this patch extends option CTXTID with an extra bit
ETM_OPT_CTXTID2 (bit 15), thus on an EL2 kernel, we will have another
bit available for the perf tool: ETM_OPT_CTXTID is for kernel running in
EL1, ETM_OPT_CTXTID2 is used when kernel runs in EL2 with VHE enabled.
The tool must be backward compatible for users, i.e, "contextid" today
traces PID and that should remain the same; for this purpose, the perf
tool is updated to automatically set corresponding bit for the
"contextid" config, therefore, the user doesn't have to bother which EL
the kernel is running.
i.e, perf record -e cs_etm/contextid/u --
will always do the "pid" tracing, independent of the kernel EL.
The driver parses the format "contextid", which traces CONTEXTIDR_EL1
for ETM_OPT_CTXTID (on EL1 kernel) and traces CONTEXTIDR_EL2 for
ETM_OPT_CTXTID2 (on EL2 kernel).
Besides the enhancement for format "contexid", extra two formats are
introduced: "contextid1" and "contextid2". This considers to support
tracing both CONTEXTIDR_EL1 and CONTEXTIDR_EL2 when the kernel is
running at EL2. Finally, the PMU formats are defined as follow:
"contextid1": Available on both EL1 kernel and EL2 kernel. When the
kernel is running at EL1, "contextid1" enables the PID
tracing; when the kernel is running at EL2, this enables
tracing the PID of guest applications.
"contextid2": Only usable when the kernel is running at EL2. When
selected, enables PID tracing on EL2 kernel.
"contextid": Will be an alias for the option that enables PID
tracing. I.e,
contextid == contextid1, on EL1 kernel.
contextid == contextid2, on EL2 kernel.
Bug: 174685394
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Al Grant <al.grant@arm.com>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Leo Yan <leo.yan@linaro.org>
Reviewed-by: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
[ Added two config formats: contextid1, contextid2 ]
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20210206150833.42120-4-leo.yan@linaro.org
Link: https://lore.kernel.org/r/20210211172038.2483517-3-mathieu.poirier@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 88f11864cf)
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
Change-Id: Ied5b90940eb99386e70ad977ed10dd8ef0bd40e6
In theory, the options should be arbitrary values and are neutral for
any ETM version; so far perf tool uses ETMv3.5/PTM ETMCR config bits
except for register's bit definitions, also uses as options.
This can introduce confusion, especially if we want to add a new option
but the new option is not supported by ETMv3.5/PTM ETMCR. But on the
other hand, we cannot change options since these options are generic
CoreSight PMU ABI.
For easier maintenance and avoid confusion, this patch refines the
comment to clarify perf options, and gives out the background info for
these bits are coming from ETMv3.5/PTM. Afterwards, we should take
these options as general knobs, and if there have any confliction with
ETMv3.5/PTM, should consider to define saperate macros for ETMv3.5/PTM
ETMCR config bits.
Bug: 174685394
Suggested-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20210206150833.42120-2-leo.yan@linaro.org
Link: https://lore.kernel.org/r/20210211172038.2483517-2-mathieu.poirier@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 53abf3fe83)
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
Change-Id: I39e8f7f4e2e46d91b54633d109a5f6b6ce44754c
This was non-trivial to get right because commits
c23bc382ef ("coresight: etm4x: Refactor probing routine") and
5214b56358 ("coresight: etm4x: Add support for sysreg only devices")
changed the code flow considerably. With this change the driver can be
built again.
Bug: 174685394
Fixes: 0573d3fa48 ("Merge branch 'devel-stable' of git://git.armlinux.org.uk/~rmk/linux-arm into char-misc-next")
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Link: https://lore.kernel.org/r/20210205130848.20009-1-uwe@kleine-koenig.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1609faa9e6)
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
Change-Id: Ifbd89b1e5015793e951a1cafd6c7ebdf345c0389
Some of the ETM management registers are not accessible via
system instructions. Thus we need to filter accesses to these
registers depending on the access mechanism for the ETM at runtime.
The driver can cope with this for normal operation, by regular
checks. But the driver also exposes them via sysfs, which now
needs to be removed.
So far, we have used the generic coresight sysfs helper macros
to export a given device register, defining a "show" operation
per register. This is not helpful to filter the files at runtime,
based on the access.
In order to do this dynamically, we need to filter the attributes
by offsets and hard coded "show" functions doesn't make this easy.
Thus, switch to extended attributes, storing the offset in the scratch
space. This allows us to implement filtering based on the offset and
also saves us some text size. This will be later used for determining
a given attribute must be "visible" via sysfs.
Bug: 174685394
Link: https://lore.kernel.org/r/20210110224850.1880240-10-suzuki.poulose@arm.com
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20210201181351.1475223-12-mathieu.poirier@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c03ceec116)
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
Change-Id: I970e464e881b1d6eda10b2bfb49c0750668374e8
Convert all register accesses from etm4x driver to use a wrapper
to allow switching the access at runtime with little overhead.
co-developed by sed tool ;-), mostly equivalent to :
s/readl\(_relaxed\)\?(drvdata->base + \(.*\))/etm4x_\1_read32(csdev, \2)
s/writel\(_relaxed\)\?(\(.*\), drvdata->base + \(.*\))/etm4x_\1_write32(csdev, \2, \3)
We don't want to replace them with the csdev_access_* to
avoid a function call for every register access for system
register access. This is a prepartory step to add system
register access later where the support is available.
Bug: 174685394
Link: https://lore.kernel.org/r/20210110224850.1880240-9-suzuki.poulose@arm.com
Cc: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20210201181351.1475223-11-mathieu.poirier@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f5bd523690)
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
Change-Id: I2b961597fca826b4d608c417869b820828941cb9
The ETM device can't keep up with the core pipeline when cpu core
is at full speed. This may cause overflow within core and its ETM.
This is a common phenomenon on ETM devices.
On HiSilicon Hip08 platform, a specific feature is added to set
core pipeline. So commit rate can be reduced manually to avoid ETM
overflow.
Bug: 174685394
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Qi Liu <liuqi115@huawei.com>
[Modified changelog title and Kconfig description]
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20201208182651.1597945-4-mathieu.poirier@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e72550928f)
Signed-off-by: Qais Yousef <qais.yousef@arm.com>
Change-Id: I871af35685ae02a04fee437d514bc05a49c63e56
This is needed to redirect packets from one interface to another.
Bug: 181230766
Change-Id: I0c74c69906246a98d24951e959e59d771caa6046
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Update abi_gki_aarch64_qcom to include symbols used by
zram and zsmalloc modules.
Bug: 180997582
Change-Id: I1427696610c64f99351350929da315724594b054
Signed-off-by: Sudarshan Rajagopalan <sudaraja@codeaurora.org>
Signed-off-by: Chris Goldsworthy <cgoldswo@codeaurora.org>
The rt sync wakeup support has a condition which relies on a field that
exists only when CONFIG_SMP is defined, causing a compilation issue.
Since sync wakeup has no real meaning on a non-SMP system, we can just
drop the CONFIG_RT_GROUP_SCHED part of the #ifdef.
Fixes: da5f3cd378 ("ANDROID: sched/rt: Add support for rt sync wakeups")
Signed-off-by: J. Avila <elavila@google.com>
Change-Id: I9b95304408d323b0c1017bd33746ecfbb2b35808
Backing file needs to have write permissions for all users
even though the mounted view doesn't - otherwise incfs can't
change the internal file data.
Bug: 180535478
Test: adb install <apk>
Signed-off-by: Yurii Zubrytskyi <zyy@google.com>
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I5d7915b28072cff1508ba45b56e844cb678ca466
For incfs files that were created without a merkle tree, enabling verity
requires building a merkle tree first. Although this is the same logic
as verity performs, it is not that easy to reconcile the two given that
incfs has the merkle tree potentially when verity is not enabled.
Bug: 160634504
Test: incfs_test passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ia15a4051fa3362820846d65859e3af76b77f8cc4
Add ioctl to return the verity file digest, compatible with the identical
ioctl in fs/verity/.
Bug: 160634504
Test: incfs_test passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I1bc2dc975b9be122e1c831a25a1d44f27a360f3c
Now fsverity state is preserved across inode eviction.
Added incfs.verity xattr to track when a file is fs-verity enabled.
Bug: 160634504
Test: incfs_test passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I41d90abd55527884d9eff642c9834ad837ff6918
Add FS_IOC_GETFLAGS ioctl to incfs. Currently this will only get the
S_VERITY flag.
Bug: 160634504
Test: incfs_test passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Id79add0db0d66f604ca0f222fe5faec91450ade5
Add FS_IOC_ENABLE_VERITY ioctl
When called, calculate measurement, validate signature against fsverity,
and set S_VERITY flag.
This does not (yet) preserve the verity status once the inode is
evicted.
Bug: 160634504
Test: incfs_test passes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I88af2721f650098accc72a64528c7d85b753c7f6
Allows a file system to provide its own fs-verity implementation
but still to hook into the signature check and control file from
fs-verity
Bug: 160634504
Bug: 170978993
Test: incfs_test running on this + subsequent changes
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: I02020af460d62fa5eb459a083419208e175005e8
