From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 543A0C77B7A for ; Wed, 17 May 2023 15:54:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2id9U1OlrHdDofqt8jQEapnVLjqs4THYw9Ed4kvNqmc=; b=m9Cbg5DnV7+Zmx 7L+y5Xv4ZERr5p+1xUcvFir6uPK53Wlm0+Fl70Y2GtOgsXZWjWYuDN4GJRbfX4IVZOfFxu53LLWnu i3M+n7Im1ZxmHZQ1aItIXiYeMkJXDbcMgKFQF1b+xSZRhPm79YO3F7UFpJVu7TkDW21HsXOp85Jd5 kY4v4YRrmjcNjxnv/UEKON/V8qx5aFC8g7rLlYBSJ2MWM/ndF88dAmqWaSpe1w8g9YW0jLcHXKb4e l3alVZ11G5SZgxk9xs91ZpzBWSULHdE9zx3qL1zjsCYTDdDdzpq6k7VOkJL/XhVkmNJ693G/Lft4C Ppd9zva01SG/z6z7q5LA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pzJTK-00ANIB-1a; Wed, 17 May 2023 15:53:50 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pzJTG-00ANHL-2Y for linux-arm-kernel@lists.infradead.org; Wed, 17 May 2023 15:53:48 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CE30E61C35; Wed, 17 May 2023 15:53:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06CD7C433EF; Wed, 17 May 2023 15:53:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684338825; bh=+pjU0O7f8M9zUN8A4umo9QIuzO/idoksUL+TWjtc2tg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=vOKrJM3oWPXCrzsS6UlLZWkBwu+hiVAipLRzS191TfmM8zuS6Vkr+37BPmYzXxErc lawUo5d06dod1XjHX27oXIfn2Z+olLYd/N4+vI+kpkT3dMxduIsWgIOFousENFxD8S 35vHBEoLJrDK+Lf4TQ2Oj4AXrOzrSnLjDiFk8etHxiRxHX8SWiU4I67gJTsyd+qoqK UXjQslQzgNXmsur4sznJ8KMC0l0d+hfL3pMYYi3Ktkp0cNC5Gpayza8eMXr6pUS2LF zt/gEmoD7ihMjxjZmqiJxVqfUVXta02EXENckIonl0idwl7GNdk3cOVWXleG2BmeLs XghyMqJ6wt5Eg== 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 1pzJTC-00Fu2o-NH; Wed, 17 May 2023 16:53:42 +0100 Date: Wed, 17 May 2023 16:53:42 +0100 Message-ID: <86o7mjkl89.wl-maz@kernel.org> From: Marc Zyngier To: Cornelia Huck Cc: Shameerali Kolothum Thodi , Jing Zhang , KVM , KVMARM , ARMLinux , Oliver Upton , Will Deacon , Paolo Bonzini , James Morse , Alexandru Elisei , Suzuki K Poulose , Fuad Tabba , Reiji Watanabe , Raghavendra Rao Ananta Subject: Re: [PATCH v8 0/6] Support writable CPU ID registers from userspace In-Reply-To: <877ct7x94e.fsf@redhat.com> References: <20230503171618.2020461-1-jingzhangos@google.com> <2ef9208dabe44f5db445a1061a0d5918@huawei.com> <868rdomtfo.wl-maz@kernel.org> <1a96a72e87684e2fb3f8c77e32516d04@huawei.com> <87cz30h4nx.fsf@redhat.com> <867ct8mnel.wl-maz@kernel.org> <87a5y4gy0b.fsf@redhat.com> <86353wmfj2.wl-maz@kernel.org> <877ct7x94e.fsf@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/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: cohuck@redhat.com, shameerali.kolothum.thodi@huawei.com, jingzhangos@google.com, kvm@vger.kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, oupton@google.com, will@kernel.org, pbonzini@redhat.com, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, tabba@google.com, reijiw@google.com, rananta@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230517_085346_937108_90A1689E X-CRM114-Status: GOOD ( 48.05 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 17 May 2023 16:36:49 +0100, Cornelia Huck wrote: > > On Tue, May 16 2023, Marc Zyngier wrote: > > > On Tue, 16 May 2023 15:19:00 +0100, > > Cornelia Huck wrote: > >> > >> On Tue, May 16 2023, Marc Zyngier wrote: > >> > >> > On Tue, 16 May 2023 12:55:14 +0100, > >> > Cornelia Huck wrote: > >> >> > >> >> Do you have more concrete ideas for QEMU CPU models already? Asking > >> >> because I wanted to talk about this at KVM Forum, so collecting what > >> >> others would like to do seems like a good idea :) > >> > > >> > I'm not being asked, but I'll share my thoughts anyway! ;-) > >> > > >> > I don't think CPU models are necessarily the most important thing. > >> > Specially when you look at the diversity of the ecosystem (and even > >> > the same CPU can be configured in different ways at integration > >> > time). Case in point, Neoverse N1 which can have its I/D caches made > >> > coherent or not. And the guest really wants to know which one it is > >> > (you can only lie in one direction). > >> > > >> > But being able to control the feature set exposed to the guest from > >> > userspace is a huge benefit in terms of migration. > >> > >> Certainly; the important part is that we can keep the guest ABI > >> stable... which parts match to a "CPU model" in the way other > >> architectures use it is an interesting question. It almost certainly > >> will look different from e.g. s390, where we only have to deal with a > >> single manufacturer. > >> > >> I'm wondering whether we'll end up building frankenmonster CPUs. > > > > We already do. KVM hides a bunch of things we don't want the guest to > > see, either because we don't support the feature, or that we want to > > present it with a different shape (cache topology, for example), and > > these combination don't really exist in any physical implementation. > > > > Which is why I don't really buy the "CPU model" concept as defined by > > x86 and s390. We already are in a vastly different place. > > Yes, I agree that the "named cpu models" approach probably won't work on > Arm (especially if you add other accelerators into the mix -- cpu 'foo' > with tcg is unlikely to be 100% identical to cpu 'foo' with KVM.) OTOH, > "these two cpus are not that different from each other, so we support > migration between them with a least common denominator feature/behaviour > set" seems more reasonable. It does, assuming the platform is "compatible". I realise I didn't mention the small issue of the counter frequency, which cannot be scaled. ARMv8.6 tried to specify a 1GHz counter frequency, but I still haven't see a single system having adopted it, and everyone is doing something different. We *could* always trap/emulate the counters/timers, but that quickly becomes ridiculously bad. Isn't ARM virtualisation fun? > > The way I see it, you get a bunch of architectural features that can > > be enabled/disabled depending on the underlying HW, hypervisor's > > capabilities and userspace input. On top of that, there is a layer of > > paint that tells you what is the overall implementation you could be > > running on (that's what MIDR+REVIDR+AIDR tell you) so that you can > > apply some unspeakable, uarch-specific hacks that keep the machine > > going (got to love these CPU errata). > > > >> Another interesting aspect is how KVM ends up influencing what the guest > >> sees on the CPU level, as in the case where we migrate across matching > >> CPUs, but with a different software level. I think we want userspace to > >> control that to some extent, but I'm not sure if this fully matches the > >> CPU model context. > > > > I'm not sure I get the "different software level" part. Do you mean > > VMM revisions? > > Yes. Basically, two (for migration purposes) identical machines with > different kernel/QEMU versions, but using the same QEMU compat > machine. Migrate from old to new, get more regs: works. Migrate from > new to old, get less regs: boom. Expectation would be for this to > work, and handling it from machine compat code seems very awkward. Old to new, fine. I'm not sure how we make the other way work. Actually, scratch that. I'm pretty sure we can't make it work. You'd have constraint your guest at creation time so that it doesn't use any feature that isn't available to older VMM/kernel revisions. I sense some interesting discussions next month! :D Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel