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 53496D4976C for ; Sun, 1 Dec 2024 12:22:50 +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=z9d7wyTgDJeR70TC+OcFXdJ2cQkUxdt8fmJvlHU5EsE=; b=dLyYh19NWEb+hZGyo7oY7eTU/g GN9db/G+l5D7bexzK+xMEqakMQ8riCmbt3NbEEF+AEIT6ms3Qik5zVPIs4trdC+5hDsglXVvPaY0H 7i47bZV4BCV1fPl2EzvmcW4M6d3r7beFtL1YaaIMoD55G04UW0QCfVytiSWfGAdHcYweT1gvIuAJ+ /DIqeoGP6mJibDtOQ4xQmmaRXtdEQuMqaJtQPv2lpsQBpRvZcUAMGtu1xIDdsA2eihYkVQwwHzYuS DXSvZvU8YwHeZklaxuMErnVA8AyksXUkU5gZ/+DQhPLm1h0uovOOtsi+MlsNU7qeSHBbBnh/EsMTu NJ+puXXQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tHiy9-00000003Q2F-3cob; Sun, 01 Dec 2024 12:22:33 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tHixB-00000003PzG-1cS1 for linux-arm-kernel@lists.infradead.org; Sun, 01 Dec 2024 12:21:34 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 65B285C5E2F; Sun, 1 Dec 2024 12:20:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3082CC4CECF; Sun, 1 Dec 2024 12:21:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733055692; bh=4r2/wOFaxgbY5isfxo+Xp/nT3M5E4pY/PU2qBkrj+Do=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Gkgy2QdjrPnkk+E40GxpG6ntwrkv/YO+ZG80dhITkYPHEUoO/1+GPtlyyeuGTo5NJ wXcJ/aPEa6T7QZpOKGmThGq4kXH4OsDtF/H690qGQz6z3qINb6upuepVByJo5ZCGTJ t8sZzBJZbKLxFV61Zr0/yO5c/ZdtrKmx4NiKFCOHW5CzED2a6hoZjnYHQuG0uHt8yC 7d7crD+V9kmZs3Yhj4LY9MUeRf3Rf2rCpCeNlmEfrWON2lnWnBONRmT9wh+IRQp+7B IXqi+y3PO/IyH2uDDKP3KkoTV+cUrZijLikfy2nkb01Zg8J3zUfUyyjwp++c4VjJik WkebjU0e0XLBw== 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 1tHix7-00H5Lr-Pe; Sun, 01 Dec 2024 12:21:29 +0000 Date: Sun, 01 Dec 2024 12:21:29 +0000 Message-ID: <865xo3vbjq.wl-maz@kernel.org> From: Marc Zyngier To: Eric Auger Cc: Sebastian Ott , Shameerali Kolothum Thodi , "kvmarm@lists.linux.dev" , "linux-arm-kernel@lists.infradead.org" , "will@kernel.org" , "catalin.marinas@arm.com" , "oliver.upton@linux.dev" , "james.morse@arm.com" , "suzuki.poulose@arm.com" , yuzenghui , "Wangzhou (B)" , Linuxarm , "reijiw@google.com" Subject: Re: [PATCH] KVM: arm64: Make the exposed feature bits in AA64DFR0_EL1 writable from userspace In-Reply-To: References: <20240813142835.77180-1-shameerali.kolothum.thodi@huawei.com> <86v804z3lk.wl-maz@kernel.org> <4d3a7dde-e085-fa70-8859-ba153c93b615@redhat.com> <87zfllssji.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: eauger@redhat.com, sebott@redhat.com, shameerali.kolothum.thodi@huawei.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, will@kernel.org, catalin.marinas@arm.com, oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, wangzhou1@hisilicon.com, linuxarm@huawei.com, reijiw@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-20241201_042133_532193_D876518C X-CRM114-Status: GOOD ( 26.78 ) 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 Hey Eric, On Thu, 28 Nov 2024 09:31:08 +0000, Eric Auger wrote: > > Hi Marc, > > On 11/26/24 20:29, Marc Zyngier wrote: > > Finally, who is going to ensure this keeps working in the foreseeable > > future? Because while this is nice, that's not what gets deployed in > > production, as it leads to unpredictable performances. My take is that > > this thing will eventually bitrot and die. > In the context of our works to define qemu vcpu models for ARM > (https://lore.kernel.org/all/20241025101959.601048-1-eric.auger@redhat.com/) > , our current approach is to try migrating between modern HW we have > access to. The case above is migration between AmpereOne and Grace which > both should be prevalent systems. Do you think this does not make sense > at all to try migrating between those, alhough this may be challenging? I don't mind the challenge. But I'm worried this is something that looks like a reasonable idea that doesn't get any traction in practice. And the example you mention is pretty striking: who in their right mind would migrate between these two systems? If you deploy a Grace system, that's because you are making use of the GPU, and your VM is likely to require it. Conversely, if you run on an Ampere system, you don't want to use a valuable (read: bloody expensive) slot on a Grace machine. > Other cases we have looked at are migration within Ampere Altra Max > system family (which should be hopefully fine now with have CTR_EL0 > works from Sebastian upstream), mig between Graviton hosts. Wrt Ampere > Altra Max to AmpereOne, Oliver pointed out the cntfrq issue which is > blocking. > > Do you think we should restrict our studies to systems which are > "closer" to each other in terms of ARM spec rev. We throught that > migration bewteen AmpereOne And Grace would be an interesting POC and > not totally irrelevant in terms of industry. These two implementations may be close in terms of CPU features. But as systems, they are massively different, and I very much doubt they have the same deployment story. If they have one at all. The Graviton story may have more traction, but these folks have their own way of doing things, and in my experience do not give upstream much consideration. To sum it up, I'm not opposed to this work. But if we are going to carry this sort of complex emulation, I want someone to step up and promise that they will test it for the next 10 years, at the very least. Because I'm very unlikely to ever have access to any of these machines, let alone both, and I don't see people using it in practice. Thanks, M. -- Without deviation from the norm, progress is not possible.