All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: oliver.upton@linux.dev, joey.gouly@arm.com,
	suzuki.poulose@arm.com, yuzenghui@huawei.com,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	catalin.marinas@arm.com, will@kernel.org
Subject: Re: [PATCH] KVM: arm64: VHE: Initialize PMSCR_EL1
Date: Thu, 07 Nov 2024 17:59:32 +0000	[thread overview]
Message-ID: <865xoy2ad7.wl-maz@kernel.org> (raw)
In-Reply-To: <ZyytjB-Hlqw909sq@raptor>

On Thu, 07 Nov 2024 12:07:40 +0000,
Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> 
> Do you think this is an improvement (looks like a pretty big diff, but it's
> mostly refactoring, the actual change is in kvm_arm_init_debug()):
> 
> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> index ce8886122ed3..21b260b02216 100644
> --- a/arch/arm64/kvm/debug.c
> +++ b/arch/arm64/kvm/debug.c
> @@ -65,12 +65,30 @@ static void restore_guest_debug_regs(struct kvm_vcpu *vcpu)
>                 *vcpu_cpsr(vcpu) &= ~DBG_SPSR_SS;
>  }
>  
> +static bool cpu_has_spe(void)
> +{
> +       return cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),
> +                                                   ID_AA64DFR0_EL1_PMSVer);
> +}
> +
> +static bool cpu_has_trbe(void)
> +{
> +       return cpuid_feature_extract_unsigned_field(read_sysreg(id_aa64dfr0_el1),
> +                                                   ID_AA64DFR0_EL1_TraceBuffer);
> +}
> +
>  /**
>   * kvm_arm_init_debug - grab what we need for debug
>   *
> - * Currently the sole task of this function is to retrieve the initial
> - * value of mdcr_el2 so we can preserve MDCR_EL2.HPMN which has
> - * presumably been set-up by some knowledgeable bootcode.
> + * This function does two things:
> + *
> + * 1. Retrieve the initial value of mdcr_el2 so we can preserve
> + * MDCR_EL2.HPMN which has presumably been set-up by some knowledgeable
> + * bootcode.
> + *
> + * 2. Clear PMSCR_EL1.E1SPE and E0SPE when the host is running at EL2. The
> + * bits reset to an unknown value, and clearing them prevents the host from
> + * accidently profiling a virtual machine.
>   *
>   * It is called once per-cpu during CPU hyp initialisation.
>   */
> @@ -78,6 +96,9 @@ static void restore_guest_debug_regs(struct kvm_vcpu *vcpu)
>  void kvm_arm_init_debug(void)
>  {
>         __this_cpu_write(mdcr_el2, kvm_call_hyp_ret(__kvm_get_mdcr_el2));
> +
> +       if (is_kernel_in_hyp_mode() && cpu_has_spe())
> +               write_sysreg_el1(0, SYS_PMSCR);
>  }
>  
>  /**
> @@ -317,23 +338,20 @@ void kvm_arm_clear_debug(struct kvm_vcpu *vcpu)
>  
>  void kvm_arch_vcpu_load_debug_state_flags(struct kvm_vcpu *vcpu)
>  {
> -       u64 dfr0;
> -
>         /* For VHE, there is nothing to do */
>         if (has_vhe())
>                 return;
>  
> -       dfr0 = read_sysreg(id_aa64dfr0_el1);
>         /*
>          * If SPE is present on this CPU and is available at current EL,
>          * we may need to check if the host state needs to be saved.
>          */
> -       if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_PMSVer_SHIFT) &&
> +       if (cpu_has_spe() &&
>             !(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) &&
> +       if (cpu_has_trbe() &&
>             !(read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_EL1_P))
>                 vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRBE);
>  }

Sure, that's a reasonable start. Oliver is busy putting a stick of
dynamite in this code, but I'm sure he could work with something like
this.

> Two questions:
> 
> 1. As far as I can tell, KVM uses at least two functions for extracting a
> field from an ID register: the ones above, which take a _SHIFT argument for
> the field position, and the SYS_FIELD_GET ones, which take a mask argument.
> Are they equivalent, is one is preferred over the other, or they have
> different use cases?

The least verbose, the better. As for their equivalence, you should
check that.

> 2. has_vhe() vs is_kernel_in_hyp_mode(). I couldn't find any documentation
> when to use one over the other. Looks to me like has_vhe() is faster
> because uses cpu caps.

They don't mean the same thing. One is a capability, the other tells
you where you run.

> And one interesting find: when booting v6.12-rc6 (no patches on top) with
> kvm-arm.mode=protected, and when profiling the kvmtool process, I see
> unexpected buffer faults:
> 
> [    0.762373] kvm [1]: Protected hVHE mode initialized successfully
> ..
> [   84.716647] arm_spe_pmu: Unexpected buffer fault on CPU 3 [PMBSR=0x0000000094020007, PMBPTR=0xffff800088804738, PMBLIMITR=0xffff800088a03001]
> 
> Same messages with the patches applied.

No idea. I don't think anyone ever tried SPE with pKVM, and I don't
have an SPE-capable box at hand.

	M.

-- 
Without deviation from the norm, progress is not possible.

      reply	other threads:[~2024-11-07 17:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-06 12:26 [PATCH] KVM: arm64: VHE: Initialize PMSCR_EL1 Alexandru Elisei
2024-11-06 13:51 ` Marc Zyngier
2024-11-07 12:07   ` Alexandru Elisei
2024-11-07 17:59     ` Marc Zyngier [this message]

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=865xoy2ad7.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=alexandru.elisei@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oliver.upton@linux.dev \
    --cc=suzuki.poulose@arm.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.