kvmarm.lists.cs.columbia.edu archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>, Joey Gouly <joey.gouly@arm.com>,
	linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev
Subject: Re: [PATCH v2 2/2] KVM: arm64: Move FGT value configuration to vCPU state
Date: Thu, 23 Mar 2023 19:34:08 +0000	[thread overview]
Message-ID: <865yarxnwv.wl-maz@kernel.org> (raw)
In-Reply-To: <20230301-kvm-arm64-fgt-v2-2-c11c0dcf810a@kernel.org>

On Thu, 23 Mar 2023 15:48:36 +0000,
Mark Brown <broonie@kernel.org> wrote:
> 
> Currently the only fine grained traps we use are the SME ones and we decide
> if we want to manage fine grained traps for the guest and which to
> enable based on the presence of that feature. In order to support SME,
> PIE and other features where we need fine grained traps we will need to
> select per guest which traps are enabled. Move to storing the traps to
> enable in the vCPU data, updating the registers if fine grained traps
> are supported and any are enabled. In order to ensure that the fine
> grained traps are restored along with other traps there is a bit of
> asymmetry with where the registers are restored on guest exit.
> 
> Currently we always set this register to 0 when running the guest so
> unconditionally use that value for guests, future patches will configure
> this.
> 
> No functional change, though we will do additional saves of the guest
> FGT register configurations and will save and restore even if the host
> and guest states are identical.
> 
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
>  arch/arm64/include/asm/kvm_emulate.h       | 16 ++++++++++++++
>  arch/arm64/include/asm/kvm_host.h          |  2 ++
>  arch/arm64/kvm/arm.c                       |  1 +
>  arch/arm64/kvm/hyp/include/hyp/switch.h    | 35 ++++++++++++++++--------------
>  arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h |  9 ++++++++
>  5 files changed, 47 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/include/asm/kvm_emulate.h
> index b31b32ecbe2d..9f88bcfdff70 100644
> --- a/arch/arm64/include/asm/kvm_emulate.h
> +++ b/arch/arm64/include/asm/kvm_emulate.h
> @@ -107,6 +107,22 @@ static inline unsigned long *vcpu_hcr(struct kvm_vcpu *vcpu)
>  	return (unsigned long *)&vcpu->arch.hcr_el2;
>  }
>  
> +static inline void vcpu_reset_fgt(struct kvm_vcpu *vcpu)
> +{
> +	if (!cpus_have_const_cap(ARM64_HAS_FGT))
> +		return;
> +
> +	/*
> +	 * Enable traps for the guest by default:
> +	 *
> +	 * ACCDATA_EL1, GCSPR_EL0, GCSCRE0_EL1, GCSPR_EL1, GCSCR_EL1,
> +	 * SMPRI_EL1, TPIDR2_EL0, RCWMASK_EL1, PIRE0_EL1, PIR_EL1,
> +	 * POR_EL0, POR_EL1, S2POR_EL1, MAIR2_EL1, and AMAIR_EL1,
> +	 */
> +	__vcpu_sys_reg(vcpu, HFGRTR_EL2) = 0;
> +	__vcpu_sys_reg(vcpu, HFGWTR_EL2) = 0;
> +}
> +
>  static inline void vcpu_clear_wfx_traps(struct kvm_vcpu *vcpu)
>  {
>  	vcpu->arch.hcr_el2 &= ~HCR_TWE;
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index bcd774d74f34..d81831e36443 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -365,6 +365,8 @@ enum vcpu_sysreg {
>  	TPIDR_EL2,	/* EL2 Software Thread ID Register */
>  	CNTHCTL_EL2,	/* Counter-timer Hypervisor Control register */
>  	SP_EL2,		/* EL2 Stack Pointer */
> +	HFGRTR_EL2,	/* Fine Grained Read Traps */
> +	HFGWTR_EL2,	/* Fine Grained Write Traps */

No, this is the wrong spot. These registers describe the *guest*
state. Not the state that KVM sets for its own use. These registers
would be used by a guest hypervisor to manage traps it uses for its
own guests.

See HCR_EL2, for example, which exists both in this register file for
the EL2 guests, and kvm_vcpu_arch for KVM to manage the guest.

>  
>  	NR_SYS_REGS	/* Nothing after this line! */
>  };
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 3bd732eaf087..baa8d1a089bd 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -1205,6 +1205,7 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu,
>  	}
>  
>  	vcpu_reset_hcr(vcpu);
> +	vcpu_reset_fgt(vcpu);
>  	vcpu->arch.cptr_el2 = CPTR_EL2_DEFAULT;
>  
>  	/*
> diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> index 07d37ff88a3f..bf0183a3a82d 100644
> --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> @@ -88,33 +88,36 @@ static inline void __activate_traps_common(struct kvm_vcpu *vcpu)
>  	vcpu->arch.mdcr_el2_host = read_sysreg(mdcr_el2);
>  	write_sysreg(vcpu->arch.mdcr_el2, mdcr_el2);
>  
> -	if (cpus_have_final_cap(ARM64_SME)) {
> -		sysreg_clear_set_s(SYS_HFGRTR_EL2,
> -				   HFGxTR_EL2_nSMPRI_EL1_MASK |
> -				   HFGxTR_EL2_nTPIDR2_EL0_MASK,
> -				   0);
> -		sysreg_clear_set_s(SYS_HFGWTR_EL2,
> -				   HFGxTR_EL2_nSMPRI_EL1_MASK |
> -				   HFGxTR_EL2_nTPIDR2_EL0_MASK,
> -				   0);
> +	if (cpus_have_final_cap(ARM64_HAS_FGT)) {
> +		write_sysreg_s(__vcpu_sys_reg(vcpu, HFGRTR_EL2),
> +			       SYS_HFGRTR_EL2);
> +
> +		write_sysreg_s(__vcpu_sys_reg(vcpu, HFGWTR_EL2),
> +			       SYS_HFGWTR_EL2);
>  	}
>  }
>  
>  static inline void __deactivate_traps_common(struct kvm_vcpu *vcpu)
>  {
> +	struct kvm_cpu_context *host_ctxt;
> +
>  	write_sysreg(vcpu->arch.mdcr_el2_host, mdcr_el2);
>  
>  	write_sysreg(0, hstr_el2);
>  	if (kvm_arm_support_pmu_v3())
>  		write_sysreg(0, pmuserenr_el0);
>  
> -	if (cpus_have_final_cap(ARM64_SME)) {
> -		sysreg_clear_set_s(SYS_HFGRTR_EL2, 0,
> -				   HFGxTR_EL2_nSMPRI_EL1_MASK |
> -				   HFGxTR_EL2_nTPIDR2_EL0_MASK);
> -		sysreg_clear_set_s(SYS_HFGWTR_EL2, 0,
> -				   HFGxTR_EL2_nSMPRI_EL1_MASK |
> -				   HFGxTR_EL2_nTPIDR2_EL0_MASK);
> +	/*
> +	 * Restore the host FGT configuration here since it's managing
> +	 * traps.
> +	 */
> +	if (cpus_have_final_cap(ARM64_HAS_FGT)) {
> +		host_ctxt = &this_cpu_ptr(&kvm_host_data)->host_ctxt;
> +
> +		write_sysreg_s(__vcpu_sys_reg(vcpu, HFGRTR_EL2),
> +			       SYS_HFGRTR_EL2);
> +		write_sysreg_s(__vcpu_sys_reg(vcpu, HFGWTR_EL2),
> +			       SYS_HFGWTR_EL2);
>  	}
>  }
>  
> diff --git a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
> index 699ea1f8d409..7e67a3e27749 100644
> --- a/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
> +++ b/arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h
> @@ -19,6 +19,15 @@
>  static inline void __sysreg_save_common_state(struct kvm_cpu_context *ctxt)
>  {
>  	ctxt_sys_reg(ctxt, MDSCR_EL1)	= read_sysreg(mdscr_el1);
> +
> +	/*
> +	 * These are restored as part of trap disablement rather than
> +	 * in __sysreg_restore_common_state().
> +	 */
> +	if (cpus_have_final_cap(ARM64_HAS_FGT)) {
> +		ctxt_sys_reg(ctxt, HFGRTR_EL2) = read_sysreg_s(SYS_HFGRTR_EL2);
> +		ctxt_sys_reg(ctxt, HFGWTR_EL2) = read_sysreg_s(SYS_HFGWTR_EL2);
> +	}

I understand why this gets saved for the host, as we need to restore
it. But why does it need to be saved for the guest? Nothing changes
it, and certainly not the guest itself.

This looks pretty wrong to me.

	M.

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

  reply	other threads:[~2023-03-23 19:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-23 15:48 [PATCH v2 0/2] KVM: arm64: Support for per-guest fine grained traps configuration Mark Brown
2023-03-23 15:48 ` [PATCH v2 1/2] arm64: Add feature detection for fine grained traps Mark Brown
2023-03-23 15:48 ` [PATCH v2 2/2] KVM: arm64: Move FGT value configuration to vCPU state Mark Brown
2023-03-23 19:34   ` Marc Zyngier [this message]
2023-03-23 22:08     ` Mark Brown
2023-03-28 15:27   ` Will Deacon
2023-03-28 15:44     ` Mark Brown

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=865yarxnwv.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=james.morse@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).