linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Christoffer Dall <cdall@cs.columbia.edu>,
	Marc Zyngier <maz@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>
Cc: Alexandru Elisei <alexandru.elisei@arm.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Oliver Upton <oupton@google.com>
Subject: linux-next: manual merge of the kvm-arm tree with the arm64 tree
Date: Wed, 4 May 2022 14:35:29 +1000	[thread overview]
Message-ID: <20220504143529.4060ab27@canb.auug.org.au> (raw)

[-- Attachment #1: Type: text/plain, Size: 4814 bytes --]

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in:

  arch/arm64/kvm/sys_regs.c

between commit:

  0b12620fddb8 ("KVM: arm64: Treat ESR_EL2 as a 64-bit register")

from the arm64 tree and commits:

  e65197666773 ("KVM: arm64: Wire up CP15 feature registers to their AArch64 equivalents")
  9369bc5c5e35 ("KVM: arm64: Plumb cp10 ID traps through the AArch64 sysreg handler")

from the kvm-arm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/kvm/sys_regs.c
index a4ef986adb5e,031d913cd79e..000000000000
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@@ -2351,6 -2355,123 +2355,123 @@@ static int kvm_handle_cp_64(struct kvm_
  	return 1;
  }
  
+ static bool emulate_sys_reg(struct kvm_vcpu *vcpu, struct sys_reg_params *params);
+ 
+ /*
+  * The CP10 ID registers are architecturally mapped to AArch64 feature
+  * registers. Abuse that fact so we can rely on the AArch64 handler for accesses
+  * from AArch32.
+  */
 -static bool kvm_esr_cp10_id_to_sys64(u32 esr, struct sys_reg_params *params)
++static bool kvm_esr_cp10_id_to_sys64(u64 esr, struct sys_reg_params *params)
+ {
+ 	u8 reg_id = (esr >> 10) & 0xf;
+ 	bool valid;
+ 
+ 	params->is_write = ((esr & 1) == 0);
+ 	params->Op0 = 3;
+ 	params->Op1 = 0;
+ 	params->CRn = 0;
+ 	params->CRm = 3;
+ 
+ 	/* CP10 ID registers are read-only */
+ 	valid = !params->is_write;
+ 
+ 	switch (reg_id) {
+ 	/* MVFR0 */
+ 	case 0b0111:
+ 		params->Op2 = 0;
+ 		break;
+ 	/* MVFR1 */
+ 	case 0b0110:
+ 		params->Op2 = 1;
+ 		break;
+ 	/* MVFR2 */
+ 	case 0b0101:
+ 		params->Op2 = 2;
+ 		break;
+ 	default:
+ 		valid = false;
+ 	}
+ 
+ 	if (valid)
+ 		return true;
+ 
+ 	kvm_pr_unimpl("Unhandled cp10 register %s: %u\n",
+ 		      params->is_write ? "write" : "read", reg_id);
+ 	return false;
+ }
+ 
+ /**
+  * kvm_handle_cp10_id() - Handles a VMRS trap on guest access to a 'Media and
+  *			  VFP Register' from AArch32.
+  * @vcpu: The vCPU pointer
+  *
+  * MVFR{0-2} are architecturally mapped to the AArch64 MVFR{0-2}_EL1 registers.
+  * Work out the correct AArch64 system register encoding and reroute to the
+  * AArch64 system register emulation.
+  */
+ int kvm_handle_cp10_id(struct kvm_vcpu *vcpu)
+ {
+ 	int Rt = kvm_vcpu_sys_get_rt(vcpu);
 -	u32 esr = kvm_vcpu_get_esr(vcpu);
++	u64 esr = kvm_vcpu_get_esr(vcpu);
+ 	struct sys_reg_params params;
+ 
+ 	/* UNDEF on any unhandled register access */
+ 	if (!kvm_esr_cp10_id_to_sys64(esr, &params)) {
+ 		kvm_inject_undefined(vcpu);
+ 		return 1;
+ 	}
+ 
+ 	if (emulate_sys_reg(vcpu, &params))
+ 		vcpu_set_reg(vcpu, Rt, params.regval);
+ 
+ 	return 1;
+ }
+ 
+ /**
+  * kvm_emulate_cp15_id_reg() - Handles an MRC trap on a guest CP15 access where
+  *			       CRn=0, which corresponds to the AArch32 feature
+  *			       registers.
+  * @vcpu: the vCPU pointer
+  * @params: the system register access parameters.
+  *
+  * Our cp15 system register tables do not enumerate the AArch32 feature
+  * registers. Conveniently, our AArch64 table does, and the AArch32 system
+  * register encoding can be trivially remapped into the AArch64 for the feature
+  * registers: Append op0=3, leaving op1, CRn, CRm, and op2 the same.
+  *
+  * According to DDI0487G.b G7.3.1, paragraph "Behavior of VMSAv8-32 32-bit
+  * System registers with (coproc=0b1111, CRn==c0)", read accesses from this
+  * range are either UNKNOWN or RES0. Rerouting remains architectural as we
+  * treat undefined registers in this range as RAZ.
+  */
+ static int kvm_emulate_cp15_id_reg(struct kvm_vcpu *vcpu,
+ 				   struct sys_reg_params *params)
+ {
+ 	int Rt = kvm_vcpu_sys_get_rt(vcpu);
+ 
+ 	/* Treat impossible writes to RO registers as UNDEFINED */
+ 	if (params->is_write) {
+ 		unhandled_cp_access(vcpu, params);
+ 		return 1;
+ 	}
+ 
+ 	params->Op0 = 3;
+ 
+ 	/*
+ 	 * All registers where CRm > 3 are known to be UNKNOWN/RAZ from AArch32.
+ 	 * Avoid conflicting with future expansion of AArch64 feature registers
+ 	 * and simply treat them as RAZ here.
+ 	 */
+ 	if (params->CRm > 3)
+ 		params->regval = 0;
+ 	else if (!emulate_sys_reg(vcpu, params))
+ 		return 1;
+ 
+ 	vcpu_set_reg(vcpu, Rt, params->regval);
+ 	return 1;
+ }
+ 
  /**
   * kvm_handle_cp_32 -- handles a mrc/mcr trap on a guest CP14/CP15 access
   * @vcpu: The VCPU pointer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

             reply	other threads:[~2022-05-04  4:35 UTC|newest]

Thread overview: 83+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-04  4:35 Stephen Rothwell [this message]
2022-05-04  7:06 ` linux-next: manual merge of the kvm-arm tree with the arm64 tree Marc Zyngier
2022-05-04  8:08   ` Catalin Marinas
2022-05-23  6:36 ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2024-03-08  1:54 Stephen Rothwell
2024-03-08  6:25 ` Oliver Upton
2024-03-08 12:30   ` Catalin Marinas
2024-03-08  1:47 Stephen Rothwell
2024-02-20  2:21 Stephen Rothwell
2024-02-19  2:58 Stephen Rothwell
2024-02-19 12:14 ` Catalin Marinas
2024-02-19 15:22   ` Marc Zyngier
2024-02-19 15:35     ` Mark Rutland
2024-02-19 15:43     ` Ard Biesheuvel
2024-02-19 16:49     ` Catalin Marinas
2023-10-24  2:28 Stephen Rothwell
2023-10-24  6:49 ` Oliver Upton
2023-10-17  1:30 Stephen Rothwell
2023-10-17 11:13 ` Catalin Marinas
2023-10-18 23:02   ` Oliver Upton
2023-11-01  2:36 ` Stephen Rothwell
2023-06-15  2:45 Stephen Rothwell
2023-06-15  7:37 ` Oliver Upton
2023-06-15  8:32   ` Catalin Marinas
2023-06-15  2:22 Stephen Rothwell
2023-06-15  7:14 ` Catalin Marinas
2023-07-03  0:50 ` Stephen Rothwell
2023-06-06  1:49 Stephen Rothwell
2023-06-06  9:20 ` Catalin Marinas
2023-06-07  1:05 ` Stephen Rothwell
2023-06-07  5:33   ` Oliver Upton
2023-06-07  8:45     ` Catalin Marinas
2023-02-06  1:44 Stephen Rothwell
2023-02-06  4:21 ` Stephen Rothwell
2023-02-06  8:37 ` Marc Zyngier
2023-02-06  8:43   ` Marc Zyngier
2022-09-19  4:05 Stephen Rothwell
2022-09-19  9:04 ` Marc Zyngier
2022-09-23 10:26   ` Catalin Marinas
2021-08-19  4:05 Stephen Rothwell
2021-08-20  9:27 ` Catalin Marinas
2021-08-12  3:33 Stephen Rothwell
2021-06-23  5:58 Stephen Rothwell
2021-04-13  5:43 Stephen Rothwell
2021-04-13 11:21 ` Ard Biesheuvel
2021-01-27  5:24 Stephen Rothwell
2020-12-04  5:44 Stephen Rothwell
2020-12-04 11:12 ` Marc Zyngier
2020-12-04  5:17 Stephen Rothwell
2020-09-30  6:26 Stephen Rothwell
2020-05-29  7:00 Stephen Rothwell
2019-07-08  7:24 Stephen Rothwell
2018-10-04  4:22 Stephen Rothwell
2018-10-04  4:07 Stephen Rothwell
2018-07-23  4:46 Stephen Rothwell
2018-07-23 10:45 ` Marc Zyngier
2018-08-16  0:15 ` Stephen Rothwell
2018-08-17  8:32   ` Paolo Bonzini
2018-08-17  9:33     ` Marc Zyngier
2018-06-01  6:23 Stephen Rothwell
2018-06-01  8:23 ` Marc Zyngier
2018-06-01  6:13 Stephen Rothwell
2018-03-28  5:05 Stephen Rothwell
2018-03-29  5:16 ` Stephen Rothwell
2018-03-28  5:00 Stephen Rothwell
2018-03-28 11:53 ` Will Deacon
2017-08-25  4:57 Stephen Rothwell
2017-08-25  8:11 ` Marc Zyngier
2017-08-25  8:44   ` Christoffer Dall
2016-02-29  5:18 Stephen Rothwell
2016-02-24  2:38 Stephen Rothwell
2016-02-22  2:33 Stephen Rothwell
2016-02-22  9:26 ` Catalin Marinas
2016-02-22  2:28 Stephen Rothwell
2016-02-22  9:24 ` Catalin Marinas
2016-02-12  2:26 Stephen Rothwell
2015-01-22  5:07 Stephen Rothwell
2015-01-22  8:51 ` Marc Zyngier
2015-01-22 10:29   ` Mark Rutland
2015-01-22 23:05     ` Stephen Rothwell
2015-01-23  1:36   ` Wei Huang
2015-01-23 11:53   ` Christoffer Dall
2015-01-22  5:06 Stephen Rothwell

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=20220504143529.4060ab27@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=alexandru.elisei@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=cdall@cs.columbia.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=oupton@google.com \
    --cc=will@kernel.org \
    /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).