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 C55CC1D6DB5 for ; Mon, 2 Dec 2024 09:11:40 +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=1733130700; cv=none; b=B9KYwCaeOcT8IX0c8UiM5pyHW9vMPxQytrYxPpYpmLEud3nM0cYungxiQjDgH8x4yA7tIGhYBn4oq1N/WIZY9wLow+k4d1pw+2WsiUfNPjP0bld+kOmN9cQhn1RxWIr5azS1E5T5XGVkq8scUpSsJad9Qo85dX8dVOdnjxP44To= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733130700; c=relaxed/simple; bh=d4gO9Jf7xooGuIIZIf9p1ZNAD2kR1agmYNpq7vqvVW4=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=EPZpu3sb/47qWbfMn8pl+tIsu9cG21Nsth8auCeIVqQi3lA57Gp1SVS9V3MovmAYA0ms6T4wevxlhh2M/Nc2bDOiMVUPNKB+zv4MCvMYLaaI8BtxhAF2BhgGTm1SqK5+dlh/hO0GqyVmFwvlx5hKiJJlvu6hwwacjdPBtKgVDBw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=P7MiETio; 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="P7MiETio" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 250F6C4CED2; Mon, 2 Dec 2024 09:11:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733130700; bh=d4gO9Jf7xooGuIIZIf9p1ZNAD2kR1agmYNpq7vqvVW4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=P7MiETioPL8TsoCxnTE8srof9HzUBtTQmdPMjaETyF7aEyyLIgMz1cnyZQR6D3tPW BuN16y8zR7uUYz8HSxC7nsFYLmVMpgjt/9mGpftY+YAqfypju4nS2XZ5gQkMXLktSg RL5h6jrDu8GvPuGlZvqEXfSgImZi3aFYNE1L518298zUNfxfv+S3D4XL0nNl40drfy aDW7JQFXfSKPw1fMka3i7OK2RiRw6PjTopfhztFEREFBulSfGYfhS0Cv/ZOlkqv2E4 a/EYgs7IDZ7wwBbqMLKmf1+k3MMzQ2lxV2pJbNtjCRH1fFdgHaqtcHNN57zDY7H5Fu vJizTP4kgl3vw== 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 1tI2Sv-00HH5d-Pa; Mon, 02 Dec 2024 09:11:37 +0000 Date: Mon, 02 Dec 2024 09:11:37 +0000 Message-ID: <86y10ytpo6.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> <865xo3vbjq.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=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 On Mon, 02 Dec 2024 08:03:26 +0000, Eric Auger wrote: > > Hi Marc, > > On 12/1/24 13:21, Marc Zyngier wrote: > > 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. > > Yes I acknowledge it is a total valid point from a use case and cost > point of view. I was expecting maybe some interest migrating between > AmpereOne and Grace-Grace for farm enhancement but most probably it is > marginal. That's my understanding as well. Cloud vendors tend to have homogeneous systems, and those who don't are realising that they shot themselves in the foot (and in that case, the debug infrastructure is the least of their worries). > Definition of [qemu] named vcpu models looks pretty uneasy then because > we don't have much relevant and accessible HW to test with, taking into > account such non technical considerations. Besides migration within a > CPU family I don't see much. That's basically my point. Another thing to consider is that there is an effort on the SBSA front to standardise which breakpoint numbers are context-aware, which would side-step the need for emulation in the long run (once the current crop of HW is gone and forgotten, which should be in the next 3 months or so ;-). But if there was a *credible* user coming out and saying that they depended on this sort of feature to be supported now and forever, then I'd be more supportive. Thanks, M. -- Without deviation from the norm, progress is not possible.