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 D0E422AD16 for ; Thu, 19 Dec 2024 15:41:59 +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=1734622919; cv=none; b=TdQRl1Lzf3W8izQ3i1trhklHCYsajP9qRMi0qU9XbRMlMknnGa53C2nUGIJ3ii4adAPo1Qm6d9mC1DIos4KBhGKVVM70+jP2KlxF6G24tKgeIxo48qKzkPmLs+Xtv8ldxqlCSeA2ZiC710rJEuwNuiIn8fMCm2v4cj+IrEuyd88= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734622919; c=relaxed/simple; bh=JT6efBVKqubwl6mff1iO/fWWnelB4X1FDGSeUIpzVXY=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=hyRstqPDIcAa70uHZd/h8wctAWAI1TxVO81XBD5RPOaL33Y1OUH1AJ49cJ5zYgNn8fqz2kdcQFzWpYXPZvkxq8LmSfFk5uKbnzUyeOOlw3egfgZkS46fIEWh9WkdzkJZ17evCNsIShXGYDu5q7NOczflhxbJs3f7HNyWuDFS36s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YtuUEpUr; 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="YtuUEpUr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 60F5EC4CECE; Thu, 19 Dec 2024 15:41:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734622919; bh=JT6efBVKqubwl6mff1iO/fWWnelB4X1FDGSeUIpzVXY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=YtuUEpUrjVn8+lKZ7otJAzgavXmA+SvAYu0KyW4vdH1VbreJ1cJKqVJvuq9QP16fW 0UKeGlyTG3T/66OwubbvqpUfWa7xSwzAKORIbC/qVSavLi9/uaRWFUPTrHxoAwFCBW anOTfhikMvHolmG8is56+dzfppsoWEXGLd1eXrl2pzw1/MQD1QSkF297wpqR3pr3Od yoK/0qenK7+PdmErk4OM1dpVQASpd8sbfVGaPKk+DIOu3cNo/5W6AC9rQKDMm+rDai aCUyWcbSsxSF1Eb+uZH9X1qium+y6ToYTTAhR/5KfgwYDAVJhfml3gsm1HXQBvahnU JgemaMgfiWVqA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.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 1tOIez-005J4X-4n; Thu, 19 Dec 2024 15:41:57 +0000 Date: Thu, 19 Dec 2024 15:41:56 +0000 Message-ID: <86zfkrptmj.wl-maz@kernel.org> From: Marc Zyngier To: Kashyap Chamarthy Cc: Eric Auger , Cornelia Huck , Daniel =?UTF-8?B?IlAuIEJlcnJhbmfDqSI=?= , eric.auger.pro@gmail.com, qemu-devel@nongnu.org, qemu-arm@nongnu.org, kvmarm@lists.linux.dev, peter.maydell@linaro.org, richard.henderson@linaro.org, alex.bennee@linaro.org, oliver.upton@linux.dev, sebott@redhat.com, shameerali.kolothum.thodi@huawei.com, armbru@redhat.com, abologna@redhat.com, jdenemar@redhat.com, shahuang@redhat.com, mark.rutland@arm.com, philmd@linaro.org, pbonzini@redhat.com Subject: Re: [PATCH RFCv2 00/20] kvm/arm: Introduce a customizable aarch64 KVM host model In-Reply-To: References: <20241206112213.88394-1-cohuck@redhat.com> <8734it1bv6.fsf@redhat.com> <1fea79e4-7a31-4592-8495-7b18cd82d02b@redhat.com> <8634ijrh8q.wl-maz@kernel.org> 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 (aarch64-unknown-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: kchamart@redhat.com, eric.auger@redhat.com, cohuck@redhat.com, berrange@redhat.com, eric.auger.pro@gmail.com, qemu-devel@nongnu.org, qemu-arm@nongnu.org, kvmarm@lists.linux.dev, peter.maydell@linaro.org, richard.henderson@linaro.org, alex.bennee@linaro.org, oliver.upton@linux.dev, sebott@redhat.com, shameerali.kolothum.thodi@huawei.com, armbru@redhat.com, abologna@redhat.com, jdenemar@redhat.com, shahuang@redhat.com, mark.rutland@arm.com, philmd@linaro.org, pbonzini@redhat.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Thu, 19 Dec 2024 15:07:25 +0000, Kashyap Chamarthy wrote: >=20 > On Thu, Dec 19, 2024 at 12:26:29PM +0000, Marc Zyngier wrote: > > On Thu, 19 Dec 2024 11:35:16 +0000, > > Kashyap Chamarthy wrote: >=20 > [...] >=20 > > > Consider this: > > >=20 > > > Say, there's a serious security issue in a released ARM CPU. As part= of > > > the fix, two new CPU flags need to be exposed to the guest OS, call t= hem > > > "secflag1" and "secflag2". Here, the user is configuring a baseline > > > model + two extra CPU flags, not to get close to some other CPU model > > > but to mitigate itself against a serious security flaw. > >=20 > > If there's such a security issue, that the hypervisor's job to do so, > > not userspace.=20 >=20 > I don't disagree. Probably that has always been the case on ARM. I > asked the above based on how QEMU on x86 handles it today. >=20 > > See what KVM does for CSV3, for example (and all the > > rest of the side-channel stuff). >=20 > Noted. From a quick look in the kernel tree, I assume you're referring > to these commits[1]. >=20 > > You can't rely on userspace for security, that'd be completely > > ludicrous. >=20 > As Dan Berrang=C3=A9 points out, it's the bog-standard way QEMU deals with > some of the CPU-related issues on x86 today. See this "important CPU > flags"[2] section in the QEMU docs. I had a look, and we do things quite differently. For example, the spec-ctrl equivalent in implemented in FW and in KVM, and is exposed by default if the HW is vulnerable. Userspace could hide that the mitigation is there, but that's the extent of the configurability. >=20 > Mind you, I'm _not_ saying this is how ARM should do it. I don't know > enough about ARM to make such remarks. >=20 > * * * >=20 > To reply to your other question on this thread[3] about "which ABI?" I > think Dan is talking about the *guest* ABI: the virtual "chipset" that > is exposed to a guest (e.g. PCI(e) topology, ACPI tables, CPU model, > etc). As I understand it, this "guest ABI" should remain predictable, > regardless of: >=20 > - whether you're updating KVM, QEMU, or the underlying physical > hardware itself; or > - if the guest is migrated, live or offline >=20 > (As you might know, QEMU's "machine types" concept allows to create a > stable guest ABI.) All of this is under control of QEMU, *except* for the "maximum" of the architectural features exposed to the guest. All you can do is *downgrade* from there, and only to a limited extent. That, in turn has a direct impact on what you call the "CPU model", which for the ARM architecture really doesn't exist. All we have is a bag of discrete features, with intricate dependencies between them. Even ignoring virtualisation: you can readily find two machines using the same CPUs (let's say Neoverse-N1), integrated by the same vendor (let's say, Ampere), in SoCs that bear the same name (Altra), and realise that they have a different feature set. Fun, isn't it? That's why I don't see CPU models as a viable thing in terms of ABI. They are an approximation of what you could have, but the ABI is elsewhere. Thanks, M. --=20 Without deviation from the norm, progress is not possible.