All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Shaoqin Huang <shahuang@redhat.com>
Cc: Marc Zyngier <maz@kernel.org>,
	kvmarm@lists.linux.dev, Eric Auger <eauger@redhat.com>,
	Sebastian Ott <sebott@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	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>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v1 1/2] KVM: arm64: Allow BT field in ID_AA64PFR1_EL1 writable
Date: Tue, 11 Jun 2024 22:58:30 -0700	[thread overview]
Message-ID: <Zmk5Bj4w_CFxrabg@linux.dev> (raw)
In-Reply-To: <20240612023553.127813-2-shahuang@redhat.com>

On Tue, Jun 11, 2024 at 10:35:51PM -0400, Shaoqin Huang wrote:
> When migrating from MtCollins to AmpereOne, the BT field value in
> ID_AA64PFR1_EL1 register is different and not writable. This causes
> the migration to fail.
> 
> The BT field means Branch Target Identification mechanism support in
> AArch64 state. The value 0 means BT is not implemented, the value 1
> means BT is implemented.
> 
> On MtCollins(Migration Src), the BT value is 0.
> On AmpereOne(Migration Dst), the BT value is 1.
> 
> As it defined in the ftr_id_aa64dfr0, the samller value is safe. So if

typo: smaller

> we make the BT field writable, on the AmpereOne(Migration Dst) the BT
> field will be overrided with value 0.
> 
> Signed-off-by: Shaoqin Huang <shahuang@redhat.com>
> ---
> But there is a question, the ARM DDI mentions from Armv8.5, the only
> permitted value is 0b01. Do you guys know if there are any consequence
> if the userspace write value 0b0 into this field? Or we should restrict
> that at some level, like in VMM or kernel level?

There's no directly visible attribute in the CPU registers to determine
what level of the architecture the implementation supports, and I
don't really want KVM to go about policing this.

The general guidance for ID register fields is that we allow userspace
to select a subset of CPU features supported by KVM / the
implementation, which in this case would include the _NI encoding for
the field. This has been slightly opinionated so far, leaving features
that userspace selects via a separate mechanism (e.g. KVM_ARM_VCPU_INIT)
read only.

Userspace can (and should) come up with its own heuristics for
determining the feature set for the vCPU.

> ---
>  arch/arm64/kvm/sys_regs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index c9f4f387155f..8e0ea62e14e1 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -2292,7 +2292,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
>  		   ID_AA64PFR0_EL1_GIC |
>  		   ID_AA64PFR0_EL1_AdvSIMD |
>  		   ID_AA64PFR0_EL1_FP), },
> -	ID_SANITISED(ID_AA64PFR1_EL1),
> +	ID_WRITABLE(SYS_ID_AA64PFR1_EL1, ID_AA64PFR1_EL1_BT),

This doesn't compile. The macro prefixes "SYS_" to the register name.

-- 
Thanks,
Oliver

  reply	other threads:[~2024-06-12  5:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-12  2:35 [RFC PATCH v1 0/2] KVM: arm64: Making BT Field in ID_AA64PFR1_EL1 writable Shaoqin Huang
2024-06-12  2:35 ` [RFC PATCH v1 1/2] KVM: arm64: Allow BT field " Shaoqin Huang
2024-06-12  5:58   ` Oliver Upton [this message]
2024-06-12 15:45   ` kernel test robot
2024-06-14 21:08   ` kernel test robot
2024-06-12  2:35 ` [RFC PATCH v1 2/2] KVM: selftests: aarch64: Add writable test for ID_AA64PFR1_EL1 Shaoqin Huang
2024-06-12  5:30 ` [RFC PATCH v1 0/2] KVM: arm64: Making BT Field in ID_AA64PFR1_EL1 writable Oliver Upton
2024-06-12  9:15   ` Shaoqin Huang
2024-06-12 10:07   ` Marc Zyngier
2024-06-13  8:31     ` Shaoqin Huang
2024-06-13  8:38       ` Oliver Upton
2024-06-13  8:42       ` Marc Zyngier
2024-06-17 12:29         ` Shaoqin Huang

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=Zmk5Bj4w_CFxrabg@linux.dev \
    --to=oliver.upton@linux.dev \
    --cc=catalin.marinas@arm.com \
    --cc=cohuck@redhat.com \
    --cc=eauger@redhat.com \
    --cc=james.morse@arm.com \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=sebott@redhat.com \
    --cc=shahuang@redhat.com \
    --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.