From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 91BE61624CA; Sat, 15 Feb 2025 16:42:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739637721; cv=none; b=H+Ac8kgpVYjbCER70ofIFrc4AoFsIw6Jy6j3HKVYkcevyyjMqMTeGo4amYSBQXMthJF5cmuVhjsNptMNsXHiq8r0ClnOQJ/0UiBYiWrcFXZ0bAoK/j6LhAea9FdKAebQTlsaiT6oL0aW1k9FqXU94Lj40FWQ1nRbntmZs7GEJxM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739637721; c=relaxed/simple; bh=MBdSKSQl5qKoLwg1wjEtWvk67McJc5SXlc6YFBBxgZI=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=jBzf0cBwDia9DySQmHgQ05rFNIAfUMhGCoUlarUzl/pz2L01ZrS97ZzCvDbTCNKmQx3yWrBz+yBSLj0y/O763pPjCH95TbI+ffYUzywChcGkUbwQ3pNNGyIE0boIHv3apt2Xe4kBzrLMyldRxSoCDBYpMEIyiYMocAFCe+bclLc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=W2iVQKjq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="W2iVQKjq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 18EB0C4CEDF; Sat, 15 Feb 2025 16:42:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739637721; bh=MBdSKSQl5qKoLwg1wjEtWvk67McJc5SXlc6YFBBxgZI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=W2iVQKjqSoa88iXkUmC/QsqLJbTtY+g+QAwHNR1pZBhxKmxqkjnWjDPt2GrnxiDWf 0kZ84IMg2EYQWnsebOIkmU8gBwChNpzvYue9sNIH92DMCafy6fFd0Qpgn6X2kRIHCA NsGCY5tVI9fhqIuvqQbVYMQ9mi9gQV0f3bj6gKaD2syFQItwqa1b9286FZ7061j+Qt roJSOZ7r/WKkY/uOm2qB5I9eUIBwOQk/FBlZh7JDASb7kWp8QQA6nbJ54qKv35neXh vdu0e7JgQRImjIdO7xb+se/fr6jchAHtneHu3ZwyspIdcBLovOAmm1hjbTuKmmo0R3 aUOfWz+3uAG7A== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tjLEs-004PKM-Vc; Sat, 15 Feb 2025 16:41:59 +0000 Date: Sat, 15 Feb 2025 16:41:55 +0000 Message-ID: <87v7tb17os.wl-maz@kernel.org> From: Marc Zyngier To: luoyonggang@gmail.com Cc: Oliver Upton , Sebastian Ott , Joey Gouly , Suzuki K Poulose , Zenghui Yu , Catalin Marinas , Will Deacon , Shameer Kolothum , Cornelia Huck , Eric Auger , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/4] KVM: arm64: Allow userspace to change MIDR_EL1 In-Reply-To: References: <20250211143910.16775-1-sebott@redhat.com> <20250211143910.16775-2-sebott@redhat.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: luoyonggang@gmail.com, oliver.upton@linux.dev, sebott@redhat.com, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org, shameerali.kolothum.thodi@huawei.com, cohuck@redhat.com, eric.auger@redhat.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Sat, 15 Feb 2025 16:16:44 +0000, "=E7=BD=97=E5=8B=87=E5=88=9A(Yonggang Luo)" wrote: >=20 > On Sat, Feb 15, 2025 at 6:15=E2=80=AFPM Oliver Upton wrote: > > > > Hi Sebastian, > > > > On Tue, Feb 11, 2025 at 03:39:07PM +0100, Sebastian Ott wrote: > > > +static int set_id_reg_non_ftr(struct kvm_vcpu *vcpu, const struct sy= s_reg_desc *rd, > > > + u64 val) > > > +{ > > > + u32 id =3D reg_to_encoding(rd); > > > + int ret; > > > + > > > + mutex_lock(&vcpu->kvm->arch.config_lock); > > > > There's quite a few early outs, guard() might be a better fit than > > explicitly dropping the lock. > > > > > + /* > > > + * Since guest access to MIDR_EL1 is not trapped > > > + * set up VPIDR_EL2 to hold the MIDR_EL1 value. > > > + */ > > > + if (id =3D=3D SYS_MIDR_EL1) > > > + write_sysreg(val, vpidr_el2); > > > > This is problematic for a couple reasons: > > > > - If the kernel isn't running at EL2, VPIDR_EL2 is undefined > > > > - VPIDR_EL2 needs to be handled as part of the vCPU context, not > > written to without a running vCPU. What would happen if two vCPUs > > have different MIDR values? > > > > Here's a new diff with some hacks thrown in to handle VPIDR_EL2 > > correctly. Very lightly tested :) >=20 > Thans, I am also faced this issue, but other than this, I am also > facing a issue, after updating > MIDR_EL1, The CP15 register MIDR for aarch32 not updated. > The instruction is `MRC p15,0,,c0,c0,0 ; Read CP15 Main ID Registe= r` from > https://developer.arm.com/documentation/ddi0406/b/System-Level-Architectu= re/Protected-Memory-System-Architecture--PMSA-/CP15-registers-for-a-PMSA-im= plementation/c0--Main-ID-Register--MIDR- >=20 > The value of this instruction is not updated How do you determine that MIDR isn't updated? How do you update the userspace view? Thanks, M. --=20 Without deviation from the norm, progress is not possible.