From: Marc Zyngier <maz@kernel.org>
To: James Clark <james.clark@arm.com>
Cc: coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, suzuki.poulose@arm.com, acme@kernel.org,
oliver.upton@linux.dev, broonie@kernel.org,
James Morse <james.morse@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Mike Leach <mike.leach@linaro.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Miguel Luis <miguel.luis@oracle.com>,
Joey Gouly <joey.gouly@arm.com>, Ard Biesheuvel <ardb@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Kalesh Singh <kaleshsingh@google.com>,
Vincent Donnefort <vdonnefort@google.com>,
Ryan Roberts <ryan.roberts@arm.com>,
Fuad Tabba <tabba@google.com>,
Jing Zhang <jingzhangos@google.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 6/8] arm64: KVM: Add interface to set guest value for TRFCR register
Date: Mon, 26 Feb 2024 15:01:35 +0000 [thread overview]
Message-ID: <86cysj2rsg.wl-maz@kernel.org> (raw)
In-Reply-To: <20240226113044.228403-7-james.clark@arm.com>
On Mon, 26 Feb 2024 11:30:34 +0000,
James Clark <james.clark@arm.com> wrote:
>
> Add an interface for the Coresight driver to use to set the value of the
> TRFCR register for the guest. This register controls the exclude
This is not *for* the guest. It is the *host* value while running the
guest.
> settings for trace at different exception levels, and is used to honor
> the exclude_host and exclude_guest parameters from the Perf session.
> This will be used to later write TRFCR_EL1 on nVHE at guest switch. For
> VHE, the host trace is controlled by TRFCR_EL2 and thus we can write to
> the TRFCR_EL1 immediately. Because guest writes to the register are
> trapped, the value will persist and can't be modified.
See?
>
> Instead of adding a load of infrastructure to share the host's per-cpu
> offsets with the hypervisor, just define the new storage as a NR_CPUS
> array.
>
> Signed-off-by: James Clark <james.clark@arm.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 3 +++
> arch/arm64/kernel/image-vars.h | 1 +
> arch/arm64/kvm/debug.c | 29 +++++++++++++++++++++++++++++
> 3 files changed, 33 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 85b5477bd1b4..56b7f7eca195 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -509,6 +509,7 @@ struct kvm_host_psci_config {
> bool psci_0_1_cpu_off_implemented;
> bool psci_0_1_migrate_implemented;
> };
> +extern u64 ____cacheline_aligned kvm_guest_trfcr[NR_CPUS];
Great. So you are making it a guarantee that this is going to
ping-pong on every CPU that accesses this stuff. I'm sure my nVHE 64
core system is going to enjoy it. Not.
Look, we already have some per-CPU context: it's called kvm_host_data,
and we link to it from each and every vcpu. So as long as you're in
the context of a vcpu, you have access to it. Simples. We even have
accessors that pick the correct instance between VHE and (n/h)VHE.
What is wrong with using that?
>
> extern struct kvm_host_psci_config kvm_nvhe_sym(kvm_host_psci_config);
> #define kvm_host_psci_config CHOOSE_NVHE_SYM(kvm_host_psci_config)
> @@ -1174,6 +1175,7 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu);
> void kvm_set_pmu_events(u32 set, struct perf_event_attr *attr);
> void kvm_clr_pmu_events(u32 clr);
> bool kvm_set_pmuserenr(u64 val);
> +void kvm_etm_set_guest_trfcr(u64 trfcr_guest);
> #else
> static inline void kvm_set_pmu_events(u32 set, struct perf_event_attr *attr) {}
> static inline void kvm_clr_pmu_events(u32 clr) {}
> @@ -1181,6 +1183,7 @@ static inline bool kvm_set_pmuserenr(u64 val)
> {
> return false;
> }
> +static inline void kvm_etm_set_guest_trfcr(u64 trfcr_guest) {}
> #endif
>
> void kvm_vcpu_load_vhe(struct kvm_vcpu *vcpu);
> diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
> index 31daa1da191c..fe9e2bd7f43a 100644
> --- a/arch/arm64/kernel/image-vars.h
> +++ b/arch/arm64/kernel/image-vars.h
> @@ -59,6 +59,7 @@ KVM_NVHE_ALIAS(alt_cb_patch_nops);
>
> /* Global kernel state accessed by nVHE hyp code. */
> KVM_NVHE_ALIAS(kvm_vgic_global_state);
> +KVM_NVHE_ALIAS(kvm_guest_trfcr);
>
> /* Kernel symbols used to call panic() from nVHE hyp code (via ERET). */
> KVM_NVHE_ALIAS(nvhe_hyp_panic_handler);
> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> index 49a13e72ddd2..fe90bc7d6dd4 100644
> --- a/arch/arm64/kvm/debug.c
> +++ b/arch/arm64/kvm/debug.c
> @@ -22,6 +22,7 @@
> DBG_MDSCR_MDE)
>
> static DEFINE_PER_CPU(u64, mdcr_el2);
> +u64 ____cacheline_aligned kvm_guest_trfcr[NR_CPUS];
>
> /*
> * save/restore_guest_debug_regs
> @@ -359,3 +360,31 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
> vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
> vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRFCR);
> }
> +
> +/*
> + * Interface for the Coresight driver to use to set the value of the TRFCR
nit: s/to use//
> + * register for the guest. This register controls the exclude settings for trace
s/for the guest/for *tracing* the guest/
> + * at different exception levels, and is used to honor the exclude_host and
> + * exclude_guest parameters from the Perf session.
> + *
> + * This will be used to later write TRFCR_EL1 on nVHE at guest switch. For VHE,
> + * the host trace is controlled by TRFCR_EL2 and thus we can write to the
s/to the/to/
> + * TRFCR_EL1 immediately. Because guest writes to the register are trapped, the
> + * value will persist and can't be modified. For pKVM, kvm_guest_trfcr can't
> + * be read by the hypervisor, so don't bother writing it.
I don't know what you mean by "can't be read". Because controlling all
of the EL1 memory is not enough?
> + */
> +void kvm_etm_set_guest_trfcr(u64 trfcr_guest)
> +{
> + if (WARN_ON_ONCE(!cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),
> + ID_AA64DFR0_EL1_TraceFilt_SHIFT)))
> + return;
> +
> + /* Warn in invalid use of smp_processor_id() */
> + WARN_ON_ONCE(preemptible());
What does it buy us to WARN, but continue to do the *wrong* thing?
> +
> + if (has_vhe())
> + write_sysreg_s(trfcr_guest, SYS_TRFCR_EL12);
Please use write_sysreg_el1() instead.
> + else if (!is_protected_kvm_enabled())
> + kvm_guest_trfcr[smp_processor_id()] = trfcr_guest;
> +}
> +EXPORT_SYMBOL_GPL(kvm_etm_set_guest_trfcr);
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: James Clark <james.clark@arm.com>
Cc: coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev, suzuki.poulose@arm.com, acme@kernel.org,
oliver.upton@linux.dev, broonie@kernel.org,
James Morse <james.morse@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Mike Leach <mike.leach@linaro.org>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Miguel Luis <miguel.luis@oracle.com>,
Joey Gouly <joey.gouly@arm.com>, Ard Biesheuvel <ardb@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Arnd Bergmann <arnd@arndb.de>,
Kalesh Singh <kaleshsingh@google.com>,
Vincent Donnefort <vdonnefort@google.com>,
Ryan Roberts <ryan.roberts@arm.com>,
Fuad Tabba <tabba@google.com>,
Jing Zhang <jingzhangos@google.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6 6/8] arm64: KVM: Add interface to set guest value for TRFCR register
Date: Mon, 26 Feb 2024 15:01:35 +0000 [thread overview]
Message-ID: <86cysj2rsg.wl-maz@kernel.org> (raw)
In-Reply-To: <20240226113044.228403-7-james.clark@arm.com>
On Mon, 26 Feb 2024 11:30:34 +0000,
James Clark <james.clark@arm.com> wrote:
>
> Add an interface for the Coresight driver to use to set the value of the
> TRFCR register for the guest. This register controls the exclude
This is not *for* the guest. It is the *host* value while running the
guest.
> settings for trace at different exception levels, and is used to honor
> the exclude_host and exclude_guest parameters from the Perf session.
> This will be used to later write TRFCR_EL1 on nVHE at guest switch. For
> VHE, the host trace is controlled by TRFCR_EL2 and thus we can write to
> the TRFCR_EL1 immediately. Because guest writes to the register are
> trapped, the value will persist and can't be modified.
See?
>
> Instead of adding a load of infrastructure to share the host's per-cpu
> offsets with the hypervisor, just define the new storage as a NR_CPUS
> array.
>
> Signed-off-by: James Clark <james.clark@arm.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 3 +++
> arch/arm64/kernel/image-vars.h | 1 +
> arch/arm64/kvm/debug.c | 29 +++++++++++++++++++++++++++++
> 3 files changed, 33 insertions(+)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 85b5477bd1b4..56b7f7eca195 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -509,6 +509,7 @@ struct kvm_host_psci_config {
> bool psci_0_1_cpu_off_implemented;
> bool psci_0_1_migrate_implemented;
> };
> +extern u64 ____cacheline_aligned kvm_guest_trfcr[NR_CPUS];
Great. So you are making it a guarantee that this is going to
ping-pong on every CPU that accesses this stuff. I'm sure my nVHE 64
core system is going to enjoy it. Not.
Look, we already have some per-CPU context: it's called kvm_host_data,
and we link to it from each and every vcpu. So as long as you're in
the context of a vcpu, you have access to it. Simples. We even have
accessors that pick the correct instance between VHE and (n/h)VHE.
What is wrong with using that?
>
> extern struct kvm_host_psci_config kvm_nvhe_sym(kvm_host_psci_config);
> #define kvm_host_psci_config CHOOSE_NVHE_SYM(kvm_host_psci_config)
> @@ -1174,6 +1175,7 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu);
> void kvm_set_pmu_events(u32 set, struct perf_event_attr *attr);
> void kvm_clr_pmu_events(u32 clr);
> bool kvm_set_pmuserenr(u64 val);
> +void kvm_etm_set_guest_trfcr(u64 trfcr_guest);
> #else
> static inline void kvm_set_pmu_events(u32 set, struct perf_event_attr *attr) {}
> static inline void kvm_clr_pmu_events(u32 clr) {}
> @@ -1181,6 +1183,7 @@ static inline bool kvm_set_pmuserenr(u64 val)
> {
> return false;
> }
> +static inline void kvm_etm_set_guest_trfcr(u64 trfcr_guest) {}
> #endif
>
> void kvm_vcpu_load_vhe(struct kvm_vcpu *vcpu);
> diff --git a/arch/arm64/kernel/image-vars.h b/arch/arm64/kernel/image-vars.h
> index 31daa1da191c..fe9e2bd7f43a 100644
> --- a/arch/arm64/kernel/image-vars.h
> +++ b/arch/arm64/kernel/image-vars.h
> @@ -59,6 +59,7 @@ KVM_NVHE_ALIAS(alt_cb_patch_nops);
>
> /* Global kernel state accessed by nVHE hyp code. */
> KVM_NVHE_ALIAS(kvm_vgic_global_state);
> +KVM_NVHE_ALIAS(kvm_guest_trfcr);
>
> /* Kernel symbols used to call panic() from nVHE hyp code (via ERET). */
> KVM_NVHE_ALIAS(nvhe_hyp_panic_handler);
> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> index 49a13e72ddd2..fe90bc7d6dd4 100644
> --- a/arch/arm64/kvm/debug.c
> +++ b/arch/arm64/kvm/debug.c
> @@ -22,6 +22,7 @@
> DBG_MDSCR_MDE)
>
> static DEFINE_PER_CPU(u64, mdcr_el2);
> +u64 ____cacheline_aligned kvm_guest_trfcr[NR_CPUS];
>
> /*
> * save/restore_guest_debug_regs
> @@ -359,3 +360,31 @@ void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
> vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
> vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRFCR);
> }
> +
> +/*
> + * Interface for the Coresight driver to use to set the value of the TRFCR
nit: s/to use//
> + * register for the guest. This register controls the exclude settings for trace
s/for the guest/for *tracing* the guest/
> + * at different exception levels, and is used to honor the exclude_host and
> + * exclude_guest parameters from the Perf session.
> + *
> + * This will be used to later write TRFCR_EL1 on nVHE at guest switch. For VHE,
> + * the host trace is controlled by TRFCR_EL2 and thus we can write to the
s/to the/to/
> + * TRFCR_EL1 immediately. Because guest writes to the register are trapped, the
> + * value will persist and can't be modified. For pKVM, kvm_guest_trfcr can't
> + * be read by the hypervisor, so don't bother writing it.
I don't know what you mean by "can't be read". Because controlling all
of the EL1 memory is not enough?
> + */
> +void kvm_etm_set_guest_trfcr(u64 trfcr_guest)
> +{
> + if (WARN_ON_ONCE(!cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),
> + ID_AA64DFR0_EL1_TraceFilt_SHIFT)))
> + return;
> +
> + /* Warn in invalid use of smp_processor_id() */
> + WARN_ON_ONCE(preemptible());
What does it buy us to WARN, but continue to do the *wrong* thing?
> +
> + if (has_vhe())
> + write_sysreg_s(trfcr_guest, SYS_TRFCR_EL12);
Please use write_sysreg_el1() instead.
> + else if (!is_protected_kvm_enabled())
> + kvm_guest_trfcr[smp_processor_id()] = trfcr_guest;
> +}
> +EXPORT_SYMBOL_GPL(kvm_etm_set_guest_trfcr);
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-02-26 15:01 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-26 11:30 [PATCH v6 0/8] kvm/coresight: Support exclude guest and exclude host James Clark
2024-02-26 11:30 ` James Clark
2024-02-26 11:30 ` [PATCH v6 1/8] arm64: KVM: Fix renamed function in comment James Clark
2024-02-26 11:30 ` James Clark
2024-02-26 11:30 ` [PATCH v6 2/8] arm64/sysreg: Add a comment that the sysreg file should be sorted James Clark
2024-02-26 11:30 ` James Clark
2024-02-26 13:19 ` Mark Brown
2024-02-26 13:19 ` Mark Brown
2024-02-26 11:30 ` [PATCH v6 3/8] tools: arm64: Update sysreg.h header files James Clark
2024-02-26 11:30 ` James Clark
2024-02-26 11:30 ` [PATCH v6 4/8] arm64/sysreg/tools: Move TRFCR definitions to sysreg James Clark
2024-02-26 11:30 ` James Clark
2024-02-26 13:21 ` Mark Brown
2024-02-26 13:21 ` Mark Brown
2024-02-26 11:30 ` [PATCH v6 5/8] arm64: KVM: Add iflag for FEAT_TRF James Clark
2024-02-26 11:30 ` James Clark
2024-02-26 13:35 ` Marc Zyngier
2024-02-26 13:35 ` Marc Zyngier
2024-02-26 15:41 ` James Clark
2024-02-26 15:41 ` James Clark
2024-02-26 18:03 ` Marc Zyngier
2024-02-26 18:03 ` Marc Zyngier
2024-02-26 11:30 ` [PATCH v6 6/8] arm64: KVM: Add interface to set guest value for TRFCR register James Clark
2024-02-26 11:30 ` James Clark
2024-02-26 15:01 ` Marc Zyngier [this message]
2024-02-26 15:01 ` Marc Zyngier
2024-02-26 11:30 ` [PATCH v6 7/8] arm64: KVM: Write TRFCR value on guest switch with nVHE James Clark
2024-02-26 11:30 ` James Clark
2024-02-26 17:50 ` Marc Zyngier
2024-02-26 17:50 ` Marc Zyngier
2024-02-26 18:26 ` Marc Zyngier
2024-02-26 18:26 ` Marc Zyngier
2024-02-26 11:30 ` [PATCH v6 8/8] coresight: Pass guest TRFCR value to KVM James Clark
2024-02-26 11:30 ` James Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86cysj2rsg.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=anshuman.khandual@arm.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=coresight@lists.linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=james.clark@arm.com \
--cc=james.morse@arm.com \
--cc=jingzhangos@google.com \
--cc=joey.gouly@arm.com \
--cc=kaleshsingh@google.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=miguel.luis@oracle.com \
--cc=mike.leach@linaro.org \
--cc=oliver.upton@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=vdonnefort@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.