This moves remaining AMBA ACPI devices into respective platform drivers for
enabling ACPI based power management support. This series applies on kernel
v6.8-rc5 release. This series has been built, and boot tested on a DT based
(RB5) and ACPI supported coresight platform (N1SDP).
https://git.gitlab.arm.com/linux-arm/linux-anshuman.git (amba_other_acpi_migration_v5)
Cc: Lorenzo Pieralisi <lpieralisi(a)kernel.org>
Cc: Sudeep Holla <sudeep.holla(a)arm.com>
Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Cc: Mike Leach <mike.leach(a)linaro.org>
Cc: James Clark <james.clark(a)arm.com>
Cc: Maxime Coquelin <mcoquelin.stm32(a)gmail.com>
Cc: Alexandre Torgue <alexandre.torgue(a)foss.st.com>
Cc: linux-acpi(a)vger.kernel.org
Cc: linux-arm-kernel(a)lists.infradead.org
Cc: linux-kernel(a)vger.kernel.org
Cc: coresight(a)lists.linaro.org
Cc: linux-stm32(a)st-md-mailman.stormreply.com
Changes in V5:
- Used table->mask to filter out bits from pid in coresight_get_uci_data_from_amba()
- Dropped custom masks such as STM_AMBA_MASK and TMC_AMBA_MASK
- Modified tmc_etr_setup_caps() to accept struct csdev_access argument
- Reverted back tmc_etr_setup_caps() call site position in tmc_probe()
- Changed replicator and funnel devices to use the new helpers earlier in series
- Updated the commit messages regarding xxx_probe() refactoring and renaming
Changes in V4:
https://lore.kernel.org/all/20240123054608.1790189-1-anshuman.khandual@arm.…
- Fixed PM imbalance in etm4_probe() error path with pm_runtime_disable()
- Restored back the pm_runtime_disable() on platform probe error paths
in replicator, funnel, catu, tpiu, tmc and stm devices
- Dropped dev_caps argument from __tmc_probe()
- Changed xxxx_platform_remove() for platform_driver->remove_new() callback
Changes in V3:
https://lore.kernel.org/all/20231208053939.42901-1-anshuman.khandual@arm.co…
- Split coresight_init_driver/remove_driver() helpers into a separate patch
- Added 'drvdata->pclk' comments in replicator, funnel, tpiu, tmc, and stm devices
- Updated funnel, and replicator drivers to use these new helpers
- Check for drvdata instead of drvdata->pclk in suspend and resume paths in catu,
tmc and debug devices
- Added patch to extract device name from AMBA pid based table lookup for stm
- Added patch to extract device properties from AMBA pid based table look for tmc
- Dropped pm_runtime_put() from common __probe() functions
- Handled pm_runtime_put() in AMBA driver in success path
- Handled pm_runtime_put() in platform driver in both success and error paths
Changes in V2:
https://lore.kernel.org/all/20231201062053.1268492-1-anshuman.khandual@arm.…
- Dropped redundant devm_ioremap_resource() hunk from tmc_platform_probe()
- Defined coresight_[init|remove]_driver() for both AMBA/platform drivers
- Changed catu, tmc, tpiu, stm and debug coresight drivers to use the new
helpers avoiding build issues arising from module_amba_driver(), and
module_platform_driver() being on the same file
Changes in V1:
https://lore.kernel.org/all/20231027072943.3418997-1-anshuman.khandual@arm.…
- Replaced all IS_ERR() instances with IS_ERR_OR_NULL() as per Suzuki
Changes in RFC:
https://lore.kernel.org/all/20230921042040.1334641-1-anshuman.khandual@arm.…
Anshuman Khandual (11):
coresight: etm4x: Fix unbalanced pm_runtime_enable()
coresight: stm: Extract device name from AMBA pid based table lookup
coresight: tmc: Extract device properties from AMBA pid based table lookup
coresight: Add helpers registering/removing both AMBA and platform drivers
coresight: replicator: Move ACPI support from AMBA driver to platform driver
coresight: funnel: Move ACPI support from AMBA driver to platform driver
coresight: catu: Move ACPI support from AMBA driver to platform driver
coresight: tpiu: Move ACPI support from AMBA driver to platform driver
coresight: tmc: Move ACPI support from AMBA driver to platform driver
coresight: stm: Move ACPI support from AMBA driver to platform driver
coresight: debug: Move ACPI support from AMBA driver to platform driver
drivers/acpi/arm64/amba.c | 8 -
drivers/hwtracing/coresight/coresight-catu.c | 142 +++++++++++++---
drivers/hwtracing/coresight/coresight-catu.h | 1 +
drivers/hwtracing/coresight/coresight-core.c | 29 ++++
.../hwtracing/coresight/coresight-cpu-debug.c | 141 ++++++++++++++--
.../coresight/coresight-etm4x-core.c | 3 +
.../hwtracing/coresight/coresight-funnel.c | 86 +++++-----
drivers/hwtracing/coresight/coresight-priv.h | 10 ++
.../coresight/coresight-replicator.c | 81 +++++-----
drivers/hwtracing/coresight/coresight-stm.c | 115 +++++++++++--
.../hwtracing/coresight/coresight-tmc-core.c | 153 +++++++++++++++---
drivers/hwtracing/coresight/coresight-tmc.h | 2 +
drivers/hwtracing/coresight/coresight-tpiu.c | 102 ++++++++++--
include/linux/coresight.h | 7 +
14 files changed, 721 insertions(+), 159 deletions(-)
--
2.25.1
Hi,
I've long been interested in the ARM Coresight tools and played around with
OpenOCD some. I'm just now getting into OpenCSD so please forgive the noob
question but I did search the archives first.
I'm curious if the format of OpenCSD traces is such that other tools like
TraceCompass can unwind and graphically show them.
I'm wondering if I can get like LTTng type info (system wide big picture -
kernel plus userspace) out of OpenCSD but take advantage of the built in
hardware (ETM etc.) that shouldn't introduce as much latency as other tools
like LTTng, trace-cmd etc.
Thanks,
Brian
As unit of dsb element size is bit, change qcom,dsb-element-size to
qcom,dsb-elem-bits. And CMB uses -bits suffix as well. There is no
TPDM node in any DT now. Make such change before any TPDM node is added
to DT.
Change since V2:
1. Use fwnode_property_read_u32 to read the proprety value.
Change since V1:
1. Update the commit message for dt-binding.
2. Fix the dt_binding_check error for dt-binding change.
Mao Jinlong (2):
dt-bindings: arm: qcom,coresight-tpdm: Rename qcom,dsb-element-size
coresight-tpda: Change qcom,dsb-element-size to qcom,dsb-elem-bits
.../devicetree/bindings/arm/qcom,coresight-tpdm.yaml | 5 ++---
drivers/hwtracing/coresight/coresight-tpda.c | 4 ++--
drivers/hwtracing/coresight/coresight-tpda.h | 2 +-
3 files changed, 5 insertions(+), 6 deletions(-)
--
2.41.0
Although a trivial typo fix in documentation, the subject line still
might need "doc: ABI: coresight: <typo fix in tmc>" format etc but I
guess it's upto the maintainers.
On 2/27/24 00:32, Prabhav Kumar Vaish wrote:
> Changes :
> - "avaialble" corrected to "available" in "Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc"
>
> Signed-off-by: Prabhav Kumar Vaish <pvkumar5749404(a)gmail.com>
> ---
> Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
> index 96aafa66b4a5..339cec3b2f1a 100644
> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
> @@ -97,7 +97,7 @@ Date: August 2023
> KernelVersion: 6.7
> Contact: Anshuman Khandual <anshuman.khandual(a)arm.com>
> Description: (Read) Shows all supported Coresight TMC-ETR buffer modes available
> - for the users to configure explicitly. This file is avaialble only
> + for the users to configure explicitly. This file is available only
LGTM
Reviewed-by: Anshuman Khandual <anshuman.khandual(a)arm.com>
> for TMC ETR devices.
>
> What: /sys/bus/coresight/devices/<memory_map>.tmc/buf_mode_preferred
On 26/02/2024 13:35, Marc Zyngier wrote:
> On Mon, 26 Feb 2024 11:30:33 +0000,
> James Clark <james.clark(a)arm.com> wrote:
>>
>> Add an extra iflag to signify if the TRFCR register is accessible.
>
> That's not what this flag means: it indicates whether TRFCR needs to
> be saved. At lease that's what the name suggests.
>
>> Because TRBE requires FEAT_TRF, DEBUG_STATE_SAVE_TRBE still has the same
>> behavior even though it's only set when FEAT_TRF is present.
>
> This sentence seems completely out of context, because you didn't
> explain that you were making TRBE *conditional* on TRF being
> implemented, as per the architecture requirements.
>
>>
>> The following holes are left in struct kvm_vcpu_arch, but there aren't
>> enough other 8 bit fields to rearrange it to leave any hole smaller than
>> 7 bytes:
>>
>> u8 cflags; /* 2292 1 */
>> /* XXX 1 byte hole, try to pack */
>> u16 iflags; /* 2294 2 */
>> u8 sflags; /* 2296 1 */
>> bool pause; /* 2297 1 */
>> /* XXX 6 bytes hole, try to pack */
>
> I don't think that's particularly useful in a commit message, but more
> relevant to the cover letter. However, see below.
>
>>
>> Reviewed-by: Suzuki K Poulose <suzuki.poulose(a)arm.com>
>> Signed-off-by: James Clark <james.clark(a)arm.com>
>> ---
>> arch/arm64/include/asm/kvm_host.h | 4 +++-
>> arch/arm64/kvm/debug.c | 24 ++++++++++++++++++++----
>> 2 files changed, 23 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 21c57b812569..85b5477bd1b4 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -569,7 +569,7 @@ struct kvm_vcpu_arch {
>> u8 cflags;
>>
>> /* Input flags to the hypervisor code, potentially cleared after use */
>> - u8 iflags;
>> + u16 iflags;
>>
>> /* State flags for kernel bookkeeping, unused by the hypervisor code */
>> u8 sflags;
>> @@ -779,6 +779,8 @@ struct kvm_vcpu_arch {
>> #define DEBUG_STATE_SAVE_TRBE __vcpu_single_flag(iflags, BIT(6))
>> /* vcpu running in HYP context */
>> #define VCPU_HYP_CONTEXT __vcpu_single_flag(iflags, BIT(7))
>> +/* Save trace filter controls */
>> +#define DEBUG_STATE_SAVE_TRFCR __vcpu_single_flag(iflags, BIT(8))
>
> I'd rather you cherry-pick [1] and avoid expanding the iflags.
>
> [1] https://lore.kernel.org/r/20240226100601.2379693-4-maz@kernel.org
>
> Now, I think the whole SPE/TRBE/TRCR flag management should be
> improved, see below.
>
>>
>> /* SVE enabled for host EL0 */
>> #define HOST_SVE_ENABLED __vcpu_single_flag(sflags, BIT(0))
>> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
>> index ce8886122ed3..49a13e72ddd2 100644
>> --- a/arch/arm64/kvm/debug.c
>> +++ b/arch/arm64/kvm/debug.c
>> @@ -332,14 +332,30 @@ void kvm_arch_vcpu_load_debug_state_flags(struct kvm_vcpu *vcpu)
>> !(read_sysreg_s(SYS_PMBIDR_EL1) & BIT(PMBIDR_EL1_P_SHIFT)))
>> vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_SPE);
>>
>> - /* Check if we have TRBE implemented and available at the host */
>> - if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_TraceBuffer_SHIFT) &&
>> - !(read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_EL1_P))
>> - vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
>> + /*
>> + * Set SAVE_TRFCR flag if FEAT_TRF (TraceFilt) exists. This flag
>> + * signifies that the exclude_host/exclude_guest settings of any active
>> + * host Perf session on a core running a VCPU can be written into
>> + * TRFCR_EL1 on guest switch.
>> + */
>> + if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_TraceFilt_SHIFT)) {
>> + vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRFCR);
>
> Can we avoid doing this unconditionally? It only makes sense to save
> the trace crud if it is going to be changed, right?
>
Do you mean to see if kvm_guest_trfcr was non-zero (and would have to be
changed) at VCPU load? I assumed that it could be modified between load
and switch. That would mean there is no way to do it conditionally.
I also assumed that's the reason SPE and TRBE were implemented like
this, with the feat check at load and the enabled check at switch. It
doesn't feel like TRFCR is any different to those two.
Or do you mean to only set DEBUG_STATE_SAVE_TRFCR on switch if tracing
was enabled?
I suppose the names DEBUG_STATE_SAVE_SPE and DEBUG_STATE_SAVE_TRBE are
slightly misleading because neither are actually saved if they weren't
enabled. They're more like DEBUG_STATE_HAS_SPE and DEBUG_STATE_HAS_TRBE.
>> + /*
>> + * Check if we have TRBE implemented and available at the host.
>> + * If it's in use at the time of guest switch then trace will
>> + * need to be completely disabled. The architecture mandates
>> + * FEAT_TRF with TRBE, so we only need to check for TRBE after
>> + * TRF.
>> + */
>> + if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_TraceBuffer_SHIFT) &&
>> + !(read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_EL1_P))
>> + vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
>> + }
>> }
>>
>> void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
>> {
>> vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_SPE);
>> vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
>> + vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRFCR);
>> }
>
> Dealing with flags that are strongly coupled in a disjoined way a
> pretty bad idea. Look at the generated code, and realise we flip the
> preempt flag on each access.
>
> Can we do better? You bet. The vcpu_{set,clear}_flags infrastructure
> is capable of dealing with multiple flags at once, as demonstrated by
> the way we deal with exception encoding.
>
Oops yeah I didn't realize that this was more than a bit set/clear. I
will combine them. I think I could probably combine the TRBE/TRF set as
well.
Agree with the rest of the comments too.
Thanks
James
> Something like:
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index addf79ba8fa0..3e50e535fdd4 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -885,6 +885,10 @@ struct kvm_vcpu_arch {
> #define DEBUG_STATE_SAVE_SPE __vcpu_single_flag(iflags, BIT(5))
> /* Save TRBE context if active */
> #define DEBUG_STATE_SAVE_TRBE __vcpu_single_flag(iflags, BIT(6))
> +/* Save Trace Filter Controls */
> +#define DEBUG_STATE_SAVE_TRFCR __vcpu_single_flag(iflags, BIT(7))
> +/* Global debug mask */
> +#define DEBUG_STATE_SAVE_MASK __vcpu_single_flag(iflags, GENMASK(7, 5))
>
> /* SVE enabled for host EL0 */
> #define HOST_SVE_ENABLED __vcpu_single_flag(sflags, BIT(0))
> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> index 8725291cb00a..f9b197a00582 100644
> --- a/arch/arm64/kvm/debug.c
> +++ b/arch/arm64/kvm/debug.c
> @@ -339,6 +339,6 @@ void kvm_arch_vcpu_load_debug_state_flags(struct kvm_vcpu *vcpu)
>
> void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
> {
> - vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_SPE);
> - vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
> + if (!has_vhe())
> + vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_MASK);
> }
>
> Thanks,
>
> M.
>
This is a combination of the RFC for nVHE here [1] and v3 of VHE version
here [2]. After a few of the review comments it seemed much simpler for
both versions to use the same interface and be in the same patchset.
FEAT_TRF is a Coresight feature that allows trace capture to be
completely filtered at different exception levels, unlike the existing
TRCVICTLR controls which may still emit target addresses of branches,
even if the following trace is filtered.
Without FEAT_TRF, it was possible to start a trace session on a host and
also collect trace from the guest as TRCVICTLR was never programmed to
exclude guests (and it could still emit target addresses even if it
was).
With FEAT_TRF, the current behavior of trace in guests exists depends on
whether nVHE or VHE are being used. Both of the examples below are from
the host's point of view, as Coresight isn't accessible from guests.
This patchset is only relevant to when FEAT_TRF exists, otherwise there
is no change.
nVHE/pKVM:
Because the host and the guest are both using TRFCR_EL1, trace will be
generated in guests depending on the same filter rules the host is
using. For example if the host is tracing userspace only, then guest
userspace trace will also be collected.
(This is further limited by whether TRBE is used because an issue
with TRBE means that it's completely disabled in nVHE guests, but it's
possible to have other tracing components.)
VHE:
With VHE, the host filters will be in TRFCR_EL2, but the filters in
TRFCR_EL1 will be active when the guest is running. Because we don't
write to TRFCR_EL1, guest trace will be completely disabled.
With this change, the guest filtering rules from the Perf session are
now honored for both nVHE and VHE modes. This is done by either writing
to TRFCR_EL12 at the start of the Perf session and doing nothing else
further, or caching the guest value and writing it at guest switch for
nVHE. In pKVM, trace is now be disabled for both protected and
unprotected guests.
---
Changes since V4 [3]:
* Remove all V3 changes that made it work in pKVM and just disable
trace there instead
* Restore PMU host/hyp state sharing back to how it was
(kvm_pmu_update_vcpu_events())
* Simplify some of the duplication in the comments and function docs
* Add a WARN_ON_ONCE() if kvm_etm_set_guest_trfcr() is called when
the trace filtering feature doesn't exist.
* Split sysreg change into a tools update followed by the new register
addition
Changes since V3:
* Create a new shared area to store the host state instead of copying
it before each VCPU run
* Drop commit that moved SPE and trace registers from host_debug_state
into the kvm sysregs array because the guest values were never used
* Document kvm_etm_set_guest_trfcr()
* Guard kvm_etm_set_guest_trfcr() with a feature check
* Drop Mark B and Suzuki's review tags on the sysreg patch because it
turned out that broke the Perf build and needed some unconventional
changes to fix it (as in: to update the tools copy of the headers in
the same commit as the kernel changes)
Changes since V2:
* Add a new iflag to signify presence of FEAT_TRF and keep the
existing TRBE iflag. This fixes the issue where TRBLIMITR_EL1 was
being accessed even if TRBE didn't exist
* Reword a commit message
Changes since V1:
* Squashed all the arm64/tools/sysreg changes into the first commit
* Add a new commit to move SPE and TRBE regs into the kvm sysreg array
* Add a comment above the TRFCR global that it's per host CPU rather
than vcpu
Changes since nVHE RFC [1]:
* Re-write just in terms of the register value to be written for the
host and the guest. This removes some logic from the hyp code and
a value of kvm_vcpu_arch:trfcr_el1 = 0 no longer means "don't
restore".
* Remove all the conditional compilation and new files.
* Change the kvm_etm_update_vcpu_events macro to a function.
* Re-use DEBUG_STATE_SAVE_TRFCR so iflags don't need to be expanded
anymore.
* Expand the cover letter.
Changes since VHE v3 [2]:
* Use the same interface as nVHE mode so TRFCR_EL12 is now written by
kvm.
[1]: https://lore.kernel.org/kvmarm/20230804101317.460697-1-james.clark@arm.com/
[2]: https://lore.kernel.org/kvmarm/20230905102117.2011094-1-james.clark@arm.com/
[3]: https://lore.kernel.org/linux-arm-kernel/20240104162714.1062610-1-james.cla…
James Clark (7):
arm64: KVM: Fix renamed function in comment
arm64/sysreg/tools: Update tools copy of sysreg.h
arm64/sysreg/tools: Move TRFCR definitions to sysreg
arm64: KVM: Add iflag for FEAT_TRF
arm64: KVM: Add interface to set guest value for TRFCR register
arm64: KVM: Write TRFCR value on guest switch with nVHE
coresight: Pass guest TRFCR value to KVM
arch/arm64/include/asm/kvm_host.h | 7 +-
arch/arm64/include/asm/sysreg.h | 12 -
arch/arm64/kernel/image-vars.h | 1 +
arch/arm64/kvm/debug.c | 50 ++-
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 53 ++-
arch/arm64/kvm/hyp/nvhe/setup.c | 2 +-
arch/arm64/tools/sysreg | 41 ++
.../coresight/coresight-etm4x-core.c | 42 +-
drivers/hwtracing/coresight/coresight-etm4x.h | 2 +-
drivers/hwtracing/coresight/coresight-priv.h | 3 +
tools/arch/arm64/include/asm/sysreg.h | 375 +++++++++++++++++-
tools/include/linux/kasan-tags.h | 15 +
12 files changed, 541 insertions(+), 62 deletions(-)
create mode 100644 tools/include/linux/kasan-tags.h
--
2.34.1
This is a combination of the RFC for nVHE here [1] and v3 of VHE version
here [2]. After a few of the review comments it seemed much simpler for
both versions to use the same interface and be in the same patchset.
FEAT_TRF is a Coresight feature that allows trace capture to be
completely filtered at different exception levels, unlike the existing
TRCVICTLR controls which may still emit target addresses of branches,
even if the following trace is filtered.
Without FEAT_TRF, it was possible to start a trace session on a host and
also collect trace from the guest as TRCVICTLR was never programmed to
exclude guests (and it could still emit target addresses even if it
was).
With FEAT_TRF, the current behavior of trace in guests exists depends on
whether nVHE or VHE are being used. Both of the examples below are from
the host's point of view, as Coresight isn't accessible from guests.
This patchset is only relevant to when FEAT_TRF exists, otherwise there
is no change.
nVHE/pKVM:
Because the host and the guest are both using TRFCR_EL1, trace will be
generated in guests depending on the same filter rules the host is
using. For example if the host is tracing userspace only, then guest
userspace trace will also be collected.
(This is further limited by whether TRBE is used because an issue
with TRBE means that it's completely disabled in nVHE guests, but it's
possible to have other tracing components.)
VHE:
With VHE, the host filters will be in TRFCR_EL2, but the filters in
TRFCR_EL1 will be active when the guest is running. Because we don't
write to TRFCR_EL1, guest trace will be completely disabled.
With this change, the guest filtering rules from the Perf session are
now honored for both nVHE and VHE modes. This is done by either writing
to TRFCR_EL12 at the start of the Perf session and doing nothing else
further, or caching the guest value and writing it at guest switch for
nVHE. In pKVM, trace is now be disabled for both protected and
unprotected guests.
---
Changes since V5 [4]:
* Sort new sysreg entries by encoding
* Add a comment about sorting arch/arm64/tools/sysreg
* Warn on preemptible() before calling smp_processor_id()
* Pickup tags
* Change TRFCR_EL2 from SysregFields to Sysreg because it was only
used once
Changes since V4 [3]:
* Remove all V3 changes that made it work in pKVM and just disable
trace there instead
* Restore PMU host/hyp state sharing back to how it was
(kvm_pmu_update_vcpu_events())
* Simplify some of the duplication in the comments and function docs
* Add a WARN_ON_ONCE() if kvm_etm_set_guest_trfcr() is called when
the trace filtering feature doesn't exist.
* Split sysreg change into a tools update followed by the new register
addition
Changes since V3:
* Create a new shared area to store the host state instead of copying
it before each VCPU run
* Drop commit that moved SPE and trace registers from host_debug_state
into the kvm sysregs array because the guest values were never used
* Document kvm_etm_set_guest_trfcr()
* Guard kvm_etm_set_guest_trfcr() with a feature check
* Drop Mark B and Suzuki's review tags on the sysreg patch because it
turned out that broke the Perf build and needed some unconventional
changes to fix it (as in: to update the tools copy of the headers in
the same commit as the kernel changes)
Changes since V2:
* Add a new iflag to signify presence of FEAT_TRF and keep the
existing TRBE iflag. This fixes the issue where TRBLIMITR_EL1 was
being accessed even if TRBE didn't exist
* Reword a commit message
Changes since V1:
* Squashed all the arm64/tools/sysreg changes into the first commit
* Add a new commit to move SPE and TRBE regs into the kvm sysreg array
* Add a comment above the TRFCR global that it's per host CPU rather
than vcpu
Changes since nVHE RFC [1]:
* Re-write just in terms of the register value to be written for the
host and the guest. This removes some logic from the hyp code and
a value of kvm_vcpu_arch:trfcr_el1 = 0 no longer means "don't
restore".
* Remove all the conditional compilation and new files.
* Change the kvm_etm_update_vcpu_events macro to a function.
* Re-use DEBUG_STATE_SAVE_TRFCR so iflags don't need to be expanded
anymore.
* Expand the cover letter.
Changes since VHE v3 [2]:
* Use the same interface as nVHE mode so TRFCR_EL12 is now written by
kvm.
[1]: https://lore.kernel.org/kvmarm/20230804101317.460697-1-james.clark@arm.com/
[2]: https://lore.kernel.org/kvmarm/20230905102117.2011094-1-james.clark@arm.com/
[3]: https://lore.kernel.org/linux-arm-kernel/20240104162714.1062610-1-james.cla…
[4]: https://lore.kernel.org/all/20240220100924.2761706-1-james.clark@arm.com/
James Clark (8):
arm64: KVM: Fix renamed function in comment
arm64/sysreg: Add a comment that the sysreg file should be sorted
tools: arm64: Update sysreg.h header files
arm64/sysreg/tools: Move TRFCR definitions to sysreg
arm64: KVM: Add iflag for FEAT_TRF
arm64: KVM: Add interface to set guest value for TRFCR register
arm64: KVM: Write TRFCR value on guest switch with nVHE
coresight: Pass guest TRFCR value to KVM
arch/arm64/include/asm/kvm_host.h | 7 +-
arch/arm64/include/asm/sysreg.h | 12 -
arch/arm64/kernel/image-vars.h | 1 +
arch/arm64/kvm/debug.c | 53 ++-
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 53 ++-
arch/arm64/kvm/hyp/nvhe/setup.c | 2 +-
arch/arm64/tools/sysreg | 38 ++
.../coresight/coresight-etm4x-core.c | 42 +-
drivers/hwtracing/coresight/coresight-etm4x.h | 2 +-
drivers/hwtracing/coresight/coresight-priv.h | 3 +
tools/arch/arm64/include/asm/sysreg.h | 375 +++++++++++++++++-
tools/include/linux/kasan-tags.h | 15 +
12 files changed, 541 insertions(+), 62 deletions(-)
create mode 100644 tools/include/linux/kasan-tags.h
--
2.34.1
Hi Suzuki,
Is it feasible to add coresight project into patchwork.kernel.org?
It will be easier to track/manage the patches with patchwork.
--
Thanks,
Tingwei
This moves remaining AMBA ACPI devices into respective platform drivers for
enabling ACPI based power management support. This series applies on kernel
v6.8-rc1 release. This series has been built, and boot tested on a DT based
coresight platform. Although this still requires some more testing on ACPI
based coresight platforms.
https://git.gitlab.arm.com/linux-arm/linux-anshuman.git (amba_other_acpi_migration_v4)
Cc: Lorenzo Pieralisi <lpieralisi(a)kernel.org>
Cc: Sudeep Holla <sudeep.holla(a)arm.com>
Cc: Suzuki K Poulose <suzuki.poulose(a)arm.com>
Cc: Mike Leach <mike.leach(a)linaro.org>
Cc: James Clark <james.clark(a)arm.com>
Cc: Maxime Coquelin <mcoquelin.stm32(a)gmail.com>
Cc: Alexandre Torgue <alexandre.torgue(a)foss.st.com>
Cc: linux-acpi(a)vger.kernel.org
Cc: linux-arm-kernel(a)lists.infradead.org
Cc: linux-kernel(a)vger.kernel.org
Cc: coresight(a)lists.linaro.org
Cc: linux-stm32(a)st-md-mailman.stormreply.com
Changes in V4:
- Fixed PM imbalance in etm4_probe() error path with pm_runtime_disable()
- Restored back the pm_runtime_disable() on platform probe error paths
in replicator, funnel, catu, tpiu, tmc and stm devices
- Dropped dev_caps argument from __tmc_probe()
- Changed xxxx_platform_remove() for platform_driver->remove_new() callback
Changes in V3:
https://lore.kernel.org/all/20231208053939.42901-1-anshuman.khandual@arm.co…
- Split coresight_init_driver/remove_driver() helpers into a separate patch
- Added 'drvdata->pclk' comments in replicator, funnel, tpiu, tmc, and stm devices
- Updated funnel, and replicator drivers to use these new helpers
- Check for drvdata instead of drvdata->pclk in suspend and resume paths in catu,
tmc and debug devices
- Added patch to extract device name from AMBA pid based table lookup for stm
- Added patch to extract device properties from AMBA pid based table look for tmc
- Dropped pm_runtime_put() from common __probe() functions
- Handled pm_runtime_put() in AMBA driver in success path
- Handled pm_runtime_put() in platform driver in both success and error paths
Changes in V2:
https://lore.kernel.org/all/20231201062053.1268492-1-anshuman.khandual@arm.…
- Dropped redundant devm_ioremap_resource() hunk from tmc_platform_probe()
- Defined coresight_[init|remove]_driver() for both AMBA/platform drivers
- Changed catu, tmc, tpiu, stm and debug coresight drivers to use the new
helpers avoiding build issues arising from module_amba_driver(), and
module_platform_driver() being on the same file
Changes in V1:
https://lore.kernel.org/all/20231027072943.3418997-1-anshuman.khandual@arm.…
- Replaced all IS_ERR() instances with IS_ERR_OR_NULL() as per Suzuki
Changes in RFC:
https://lore.kernel.org/all/20230921042040.1334641-1-anshuman.khandual@arm.…
Anshuman Khandual (11):
coresight: etm4x: Fix unbalanced pm_runtime_enable()
coresight: stm: Extract device name from AMBA pid based table lookup
coresight: tmc: Extract device properties from AMBA pid based table lookup
coresight: Add helpers registering/removing both AMBA and platform drivers
coresight: replicator: Move ACPI support from AMBA driver to platform driver
coresight: funnel: Move ACPI support from AMBA driver to platform driver
coresight: catu: Move ACPI support from AMBA driver to platform driver
coresight: tpiu: Move ACPI support from AMBA driver to platform driver
coresight: tmc: Move ACPI support from AMBA driver to platform driver
coresight: stm: Move ACPI support from AMBA driver to platform driver
coresight: debug: Move ACPI support from AMBA driver to platform driver
drivers/acpi/arm64/amba.c | 8 -
drivers/hwtracing/coresight/coresight-catu.c | 142 +++++++++++++---
drivers/hwtracing/coresight/coresight-catu.h | 1 +
drivers/hwtracing/coresight/coresight-core.c | 29 ++++
.../hwtracing/coresight/coresight-cpu-debug.c | 141 ++++++++++++++--
.../coresight/coresight-etm4x-core.c | 3 +
.../hwtracing/coresight/coresight-funnel.c | 86 +++++-----
drivers/hwtracing/coresight/coresight-priv.h | 10 ++
.../coresight/coresight-replicator.c | 81 ++++-----
drivers/hwtracing/coresight/coresight-stm.c | 117 +++++++++++--
.../hwtracing/coresight/coresight-tmc-core.c | 158 +++++++++++++++---
drivers/hwtracing/coresight/coresight-tmc.h | 2 +
drivers/hwtracing/coresight/coresight-tpiu.c | 102 +++++++++--
include/linux/coresight.h | 7 +
14 files changed, 726 insertions(+), 161 deletions(-)
--
2.25.1