All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Mark Brown <broonie@kernel.org>,
	Luis Machado <luis.machado@arm.com>,
	Vladimir Murzin <vladimir.murzin@arm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/10] KVM: arm64: initialize HCRX_EL2
Date: Fri, 17 Mar 2023 14:25:26 +0000	[thread overview]
Message-ID: <ZBR4Vv9m11kEviDF@arm.com> (raw)
In-Reply-To: <20230216160012.272345-2-kristina.martsenko@arm.com>

On Thu, Feb 16, 2023 at 04:00:03PM +0000, Kristina Martsenko wrote:
> ARMv8.7/9.2 adds a new hypervisor configuration register HCRX_EL2.
> Initialize the register to a safe value (all fields 0), to be robust
> against firmware that has not initialized it.

I think the risk of firmware not initialising this register is small
given that EL3 needs to set SCR_EL3.HXEn to allow EL2 access. But it
doesn't hurt to re-initialise it in the hypervisor.

> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 212d93aca5e6..e06b34322339 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -572,6 +572,13 @@ SYM_INNER_LABEL(init_el2, SYM_L_LOCAL)
>  	msr	hcr_el2, x0
>  	isb
>  
> +	mrs	x0, ID_AA64MMFR1_EL1
> +	ubfx	x0, x0, #ID_AA64MMFR1_EL1_HCX_SHIFT, #4
> +	cbz	x0, 3f
> +	mov_q	x1, HCRX_HOST_FLAGS
> +	msr_s	SYS_HCRX_EL2, x1
> +	isb
> +3:
>  	init_el2_state

Nitpick: we can probably leave a single ISB after both HCR_EL2 and
HCRX_EL2 are initialised. Well, we could probably drop all of them
altogether, there's at least one down this path.

>  
>  	/* Hypervisor stub */
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> index a6d67c2bb5ae..01f854697c70 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> @@ -95,6 +95,12 @@ SYM_CODE_START_LOCAL(___kvm_hyp_init)
>  	ldr	x1, [x0, #NVHE_INIT_HCR_EL2]
>  	msr	hcr_el2, x1
>  
> +	mrs	x1, ID_AA64MMFR1_EL1
> +	ubfx	x1, x1, #ID_AA64MMFR1_EL1_HCX_SHIFT, #4
> +	cbz	x1, 1f
> +	mov_q	x2, HCRX_HOST_FLAGS
> +	msr_s	SYS_HCRX_EL2, x2
> +1:

Maybe you could use a macro to avoid writing this sequence twice. I lost
track of the KVM initialisation refactoring since pKVM, it looks like
the other register values are loaded from a structure here. I guess a
value of 0 doesn't make sense to store (unless at a later point it
becomes non-zero).

-- 
Catalin

WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
	Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	James Morse <james.morse@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Mark Brown <broonie@kernel.org>,
	Luis Machado <luis.machado@arm.com>,
	Vladimir Murzin <vladimir.murzin@arm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/10] KVM: arm64: initialize HCRX_EL2
Date: Fri, 17 Mar 2023 14:25:26 +0000	[thread overview]
Message-ID: <ZBR4Vv9m11kEviDF@arm.com> (raw)
In-Reply-To: <20230216160012.272345-2-kristina.martsenko@arm.com>

On Thu, Feb 16, 2023 at 04:00:03PM +0000, Kristina Martsenko wrote:
> ARMv8.7/9.2 adds a new hypervisor configuration register HCRX_EL2.
> Initialize the register to a safe value (all fields 0), to be robust
> against firmware that has not initialized it.

I think the risk of firmware not initialising this register is small
given that EL3 needs to set SCR_EL3.HXEn to allow EL2 access. But it
doesn't hurt to re-initialise it in the hypervisor.

> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 212d93aca5e6..e06b34322339 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -572,6 +572,13 @@ SYM_INNER_LABEL(init_el2, SYM_L_LOCAL)
>  	msr	hcr_el2, x0
>  	isb
>  
> +	mrs	x0, ID_AA64MMFR1_EL1
> +	ubfx	x0, x0, #ID_AA64MMFR1_EL1_HCX_SHIFT, #4
> +	cbz	x0, 3f
> +	mov_q	x1, HCRX_HOST_FLAGS
> +	msr_s	SYS_HCRX_EL2, x1
> +	isb
> +3:
>  	init_el2_state

Nitpick: we can probably leave a single ISB after both HCR_EL2 and
HCRX_EL2 are initialised. Well, we could probably drop all of them
altogether, there's at least one down this path.

>  
>  	/* Hypervisor stub */
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> index a6d67c2bb5ae..01f854697c70 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> @@ -95,6 +95,12 @@ SYM_CODE_START_LOCAL(___kvm_hyp_init)
>  	ldr	x1, [x0, #NVHE_INIT_HCR_EL2]
>  	msr	hcr_el2, x1
>  
> +	mrs	x1, ID_AA64MMFR1_EL1
> +	ubfx	x1, x1, #ID_AA64MMFR1_EL1_HCX_SHIFT, #4
> +	cbz	x1, 1f
> +	mov_q	x2, HCRX_HOST_FLAGS
> +	msr_s	SYS_HCRX_EL2, x2
> +1:

Maybe you could use a macro to avoid writing this sequence twice. I lost
track of the KVM initialisation refactoring since pKVM, it looks like
the other register values are loaded from a structure here. I guess a
value of 0 doesn't make sense to store (unless at a later point it
becomes non-zero).

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-03-17 14:25 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-16 16:00 [PATCH 00/10] arm64: support Armv8.8 memcpy instructions in userspace Kristina Martsenko
2023-02-16 16:00 ` Kristina Martsenko
2023-02-16 16:00 ` [PATCH 01/10] KVM: arm64: initialize HCRX_EL2 Kristina Martsenko
2023-02-16 16:00   ` Kristina Martsenko
2023-03-17 14:25   ` Catalin Marinas [this message]
2023-03-17 14:25     ` Catalin Marinas
2023-02-16 16:00 ` [PATCH 02/10] arm64: cpufeature: detect FEAT_HCX Kristina Martsenko
2023-02-16 16:00   ` Kristina Martsenko
2023-03-17 14:25   ` Catalin Marinas
2023-03-17 14:25     ` Catalin Marinas
2023-02-16 16:00 ` [PATCH 03/10] KVM: arm64: switch HCRX_EL2 between host and guest Kristina Martsenko
2023-02-16 16:00   ` Kristina Martsenko
2023-02-16 16:20   ` Mark Brown
2023-02-16 16:20     ` Mark Brown
2023-02-22 18:36     ` Kristina Martsenko
2023-02-22 18:36       ` Kristina Martsenko
2023-02-16 16:35   ` Marc Zyngier
2023-02-16 16:35     ` Marc Zyngier
2023-02-22 18:42     ` Kristina Martsenko
2023-02-22 18:42       ` Kristina Martsenko
2023-02-16 16:00 ` [PATCH 04/10] arm64: mops: document boot requirements for MOPS Kristina Martsenko
2023-02-16 16:00   ` Kristina Martsenko
2023-03-17 15:07   ` Catalin Marinas
2023-03-17 15:07     ` Catalin Marinas
2023-03-24  1:00     ` Kristina Martsenko
2023-03-24  1:00       ` Kristina Martsenko
2023-04-04 10:50       ` Catalin Marinas
2023-04-04 10:50         ` Catalin Marinas
2023-04-11 16:57         ` Kristina Martsenko
2023-04-11 16:57           ` Kristina Martsenko
2023-02-16 16:00 ` [PATCH 05/10] arm64: mops: don't disable host MOPS instructions from EL2 Kristina Martsenko
2023-02-16 16:00   ` Kristina Martsenko
2023-03-17 15:07   ` Catalin Marinas
2023-03-17 15:07     ` Catalin Marinas
2023-02-16 16:00 ` [PATCH 06/10] KVM: arm64: hide MOPS from guests Kristina Martsenko
2023-02-16 16:00   ` Kristina Martsenko
2023-03-17 15:09   ` Catalin Marinas
2023-03-17 15:09     ` Catalin Marinas
2023-02-16 16:00 ` [PATCH 07/10] arm64: mops: handle MOPS exceptions Kristina Martsenko
2023-02-16 16:00   ` Kristina Martsenko
2023-03-17 15:45   ` Catalin Marinas
2023-03-17 15:45     ` Catalin Marinas
2023-02-16 16:00 ` [PATCH 08/10] arm64: mops: handle single stepping after MOPS exception Kristina Martsenko
2023-02-16 16:00   ` Kristina Martsenko
2023-03-17 16:02   ` Catalin Marinas
2023-03-17 16:02     ` Catalin Marinas
2023-02-16 16:00 ` [PATCH 09/10] arm64: mops: detect and enable FEAT_MOPS Kristina Martsenko
2023-02-16 16:00   ` Kristina Martsenko
2023-02-16 16:22   ` Mark Brown
2023-02-16 16:22     ` Mark Brown
2023-03-17 16:03   ` Catalin Marinas
2023-03-17 16:03     ` Catalin Marinas
2023-02-16 16:00 ` [PATCH 10/10] arm64: mops: allow disabling MOPS from the kernel command line Kristina Martsenko
2023-02-16 16:00   ` Kristina Martsenko
2023-03-17 16:04   ` Catalin Marinas
2023-03-17 16:04     ` Catalin Marinas

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=ZBR4Vv9m11kEviDF@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=broonie@kernel.org \
    --cc=james.morse@arm.com \
    --cc=kristina.martsenko@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luis.machado@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=suzuki.poulose@arm.com \
    --cc=vladimir.murzin@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.