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 B3433C5321E for ; Sun, 25 Aug 2024 19:47:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=i1UqWTbWHin696ZV6w7rShDPb4s0y5RvP4ke/WaNw9Q=; b=3rOAmt+YyyvxUOXmc9OMxw2z5N FNDNDiSoSOUQWvrcq+dTaMBoKdjO+jUozHrOsXyJsr0/hWl39/H9ZVO/tPuweqACFtvn0wYLlqr6z C6o9nwge+FXS3bbYy8QbWt5nAOp6z4DCj86dI4thzSChjxgVxHU2GF9hjAGPtUcj0Xw6A8uXX89Lp 61iarOrMx2xf7qjb9PQ15Hffl+syz3+pltdN12iy5yx19ERzvXqRBdv3kkTWXmBgTBCUqEu6a8JmM N7fwy9h4BuSnvOv8k2TWM+zEDsGBx9NJu341e225xULgFQKPjWPiIiBeC3y5DuCvT1oRgUAjHrkfv nOV6F4og==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1siJCO-00000004w9Q-0rbc; Sun, 25 Aug 2024 19:46:52 +0000 Received: from sin.source.kernel.org ([2604:1380:40e1:4800::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1siJBb-00000004w2u-3N5E for linux-arm-kernel@lists.infradead.org; Sun, 25 Aug 2024 19:46:05 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id DFC16CE0AF6; Sun, 25 Aug 2024 19:45:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0BC61C4AF09; Sun, 25 Aug 2024 19:45:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724615158; bh=L2q5TZieXl7mpgEZoO9ut2SpDIoxARMxSL8SJkrTIzE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=pGa+UQ2kmpdacGgBL5te60J4MMLrx5AwRjnxKdP7y6DPLeQzDG9L+Syxn2UzDcSWW it1mT0lfNz5fZgjq5kqDnmKpRkvJi5AMc/bFwuPOy5fod+fJVHky5Ub0AaGnNstQdV mg2uVx1Qazeg2l2ykL3Rr8QYUzrTZG2e9lvdyhRfE/Utu5xtne1BMGY6m7yhQLOdRI 5xunCyiLbYyvChOPfq0z2IStOUwpu60cpBAcpC1Xyxx1P3Zs7QW6JCV6mRrVv5IHXg DdDQOzqIGRVLVdKL8xj6EKKDfHnnYokDnsIVk1i+BsbUTmLSROX20ov4sydsy+A/lG xw6ghwiXlzakQ== 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 1siJBT-006i9u-KS; Sun, 25 Aug 2024 20:45:55 +0100 Date: Sun, 25 Aug 2024 20:45:55 +0100 Message-ID: <86seuswfm4.wl-maz@kernel.org> From: Marc Zyngier To: "Russell King (Oracle)" Cc: Shaoqin Huang , Oliver Upton , kvmarm@lists.linux.dev, Mark Brown , Eric Auger , Sebastian Ott , Cornelia Huck , Catalin Marinas , James Morse , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Paolo Bonzini , Shuah Khan , Suzuki K Poulose , Will Deacon , Zenghui Yu Subject: Re: [PATCH v5 0/4] Allow userspace to change ID_AA64PFR1_EL1 In-Reply-To: References: <20240723072004.1470688-1-shahuang@redhat.com> <86ttf8wnwz.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) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: linux@armlinux.org.uk, shahuang@redhat.com, oliver.upton@linux.dev, kvmarm@lists.linux.dev, broonie@kernel.org, eauger@redhat.com, sebott@redhat.com, cohuck@redhat.com, catalin.marinas@arm.com, james.morse@arm.com, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, pbonzini@redhat.com, shuah@kernel.org, suzuki.poulose@arm.com, will@kernel.org, yuzenghui@huawei.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-20240825_124604_210765_D9C89002 X-CRM114-Status: GOOD ( 41.92 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, 25 Aug 2024 18:09:48 +0100, "Russell King (Oracle)" wrote: > > On Sun, Aug 25, 2024 at 05:46:36PM +0100, Marc Zyngier wrote: > > On Tue, 23 Jul 2024 08:19:59 +0100, > > Shaoqin Huang wrote: > > > > > > Hi guys, > > > > > > This is another try to allow userspace to change ID_AA64PFR1_EL1, and we want to > > > give userspace the ability to control the visible feature set for a VM, which > > > could be used by userspace in such a way to transparently migrate VMs. > > > > > > I think this looks OK now, thanks for going through the motions and > > doing the right thing. > > > > What is missing is similar handling for 32bit ID registers, but I'm > > not sure we keen on going down that road -- machines capable of > > running those are on their way out. This can be done later anyway, > > should anyone care. > > The Aarch32 ID registers need doing - we've already established that > fact. Sadly, you decided you wouldn't respond to my patch addressing > one of the Aarch32 ID registers despite me sending follow-ups to nicely > ask you about this - you seemed to go utterly silent on it. No, Russell. *you* went utterly silent after your May patch. You sent an RFC, to which people responded. Given that your last email on the subject was almost 4 months ago and that you never brought the subject up again, it can't be that big a deal. To me, an RFC means "I have this idea, and I'm not sure how to do it". An RFC is usually only a proof of concept that has no purpose being taken at face value. If you want a patch taken seriously, don't send it as an RFC. And send it again if nobody replies. It's not that this is anything new. > The Aarch32 ID registers have changed value between different kernel > versions, and given that QEMU saves and restores _all_ ID registers, > changes to these ID registers cause a regression if one attempts to > migrate VMs between one kernel version and the next. It doesn't even > have to be between two physical machines. Libvirt supports managed- > saving on reboot, where it saves an image of a VM at shutdown, and > restores it at the next reboot. These changes in ID registers render > effectively data loss in VMs that have been managed-saved - the > saved state of the VM has to either be destroyed, or the host kernel > reverted back and _never_ moved forward. > > As you don't seem to be keen to address this (by ignoring my emails > on the topic, and now suggesting in your response above that you're > not keen to do anything with the Aarch32 ID registers, I guess this > just means that KVM on Aarch64 is going to forever suck. I'm fine with that. Nobody is forced to use it, and I don't feel the need to put extra effort on things I don't care about any more. AArch32 support is one of these things, amongst many others. If you want the support to improve, I suggest you send patches. And send them again if no reply shows up in a timely manner. Because you're probably the last person who gives a damn about the AArch32 support in KVM. And if not even you can be bothered to fix it, then support for AArch32 EL1 should probably be removed altogether (I'm all for deleting unused code). > I'm sure Oliver will recall my emails on this which you've decided to > ignore... he was supportive of my efforts to address this. I'm supportive as well. I'm just not going to fix it for you. M. -- Without deviation from the norm, progress is not possible.