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 1106C22145D for ; Thu, 19 Dec 2024 12:26:32 +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=1734611193; cv=none; b=qVyFsn5BQsHS6BIz1snARkWN56jsf1WFzLHZMZqZziiSNi0Rfdm2PXniaEP/RVNCiuRozFbvKFvbj57MPaLJOkRKW/RAYdCt1BSDIUl2gkDrELKyFfSzSnOyquDZXIQX/6ypPzTScSLugYi6HxGrWIY8bcXHKZ/kfGSH7g3ph8w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734611193; c=relaxed/simple; bh=04mrj61m5M0eK5uxb9qdhTTuprN8gSJHsEGg321+jug=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=oGgeLq/VLxnA7rrmyakEegEGob6fhUW4DXQhZy2TAi4B1/MpQD1XnkYiVW/nQ/v/LVaVhKY40LfU2Q0Yaj+jKPjbaclklt4ZnNiDhrbnR8gOs0AmG8fF8WxaAs0BpSNTa7h+NYqFEyEYhfs5ov/JLPMnBYy6PVSGJNysHV4T9CQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Tu9FO8H0; 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="Tu9FO8H0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 876BBC4CECE; Thu, 19 Dec 2024 12:26:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734611192; bh=04mrj61m5M0eK5uxb9qdhTTuprN8gSJHsEGg321+jug=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Tu9FO8H01Fn5WM+XuIr+y7JwK+/oOLnvU7jJj6ovl99TvBJD/McqbMYuu/kRbpU5a K2prrYhSmM+4J7InIx/NZQxGvujabU4YHkeem9PDUqPerCX8sIyvrd9wDt2WiAmoQ2 fb5WjxJtfKZ26gD6kte0oWo81onM79tkmTEJnMjRZ5XRkB1iJkqM4YuzFw2ql5mCGP qB2yBT57i+/oPAmpWl66JkjZil1tK+3QyEr5m6PFs+YGnu9cz8G49sXcQnLrM00iTb nEpRbn/Iy3XEYXXM5mWr73rY8PXQLZzX3th8PBIFiPC2alQZOdiEVpTWkyI12f8nO5 SBIo6VxjVFSWw== 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 1tOFbq-005GKK-DH; Thu, 19 Dec 2024 12:26:30 +0000 Date: Thu, 19 Dec 2024 12:26:29 +0000 Message-ID: <8634ijrh8q.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> 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 11:35:16 +0000, Kashyap Chamarthy wrote: >=20 > On Thu, Dec 12, 2024 at 11:04:30AM +0100, Eric Auger wrote: >=20 > Hi Eric, >=20 > > On 12/12/24 10:36, Cornelia Huck wrote: > > > On Thu, Dec 12 2024, Daniel P. Berrang=C3=A9 wr= ote: >=20 > [...] >=20 > > >> Consider you mgmt app wants to set a CPU model that's common across > > >> heterogeneous hardware. They don't neccessarily want/need to be > > >> able to live migrate between heterogeneous CPUs, but for simplicity > > >> of configuration desire to set a single named CPU across all guests, > > >> irrespective of what host hey are launched on. The ARM spec baseline > > >> named models would give you that config simplicity. > > > If we use architecture extensions (i.e. Armv8.x/9.x) as baseline, I'm > > > seeing some drawbacks: > > > - a lot of work before we can address some specific use cases > > > - old models can get new optional features > > > - a specific cpu might have a huge set of optional features on top of > > > the baseline model > > > > > > Using a reference core such as Neoverse-V2 probably makes more sense > > > (easier to get started, less feature diff?) It would still make a good > > > starting point for a simple config. > > > > > Actually from a dev point of view I am not sure it changes much to have > > either ARM spec rev baseline or CPU ref core named model. > >=20 > > One remark is that if you look at > > https://developer.arm.com/documentation/109697/2024_09?lang=3Den > > you will see there are quite a lot of spec revisions and quite a few of > > them are actually meaningful in the light of currently avaiable and > > relevant HW we want to address. What I would like to avoid is to be > > obliged to look at all of them in a generic manner while we just want to > > address few cpu ref models. > >=20 > > Also starting from the ARM spec rev baseline the end-user may need to > > add more feature opt-ins to be close to a specific cpu model. So I > > foresee extra complexity for the end-user. >=20 > (Assuming I'm parsing your last para right; correct me if not.) >=20 > Isn't a user wanting to add extra CPU flags (on top of a baseline) a > "normal behaviour" and not "extra complexity"? Besides coming close to > a specific CPU model, there's the additional important use-case of CPU > flags that provide security mitigation. >=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 them > "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. If there's such a security issue, that the hypervisor's job to do so, not userspace. See what KVM does for CSV3, for example (and all the rest of the side-channel stuff). You can't rely on userspace for security, that'd be completely ludicrous. M. --=20 Without deviation from the norm, progress is not possible.