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 64221C27C4F for ; Thu, 13 Jun 2024 08:39:04 +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:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From: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=Bowi7EOkTndTQt3cslYbea98TP7rJlt6kYEQxSxfRQU=; b=1gRxvUGZEmzPyWoJPZQZkzYa1R cD+89r9CYp0UZ9mapwYxt5/NodUKlIVP8P3uSxaUmLRIL1yULSj7NmwF50QRJr7glR7/eKhQbHuBY GDlPi0y9PaznFH9/wZlLDzGvM1dI9YOngPSSlxUX5dH9oTC26wakoluUhM+eA3USHq8VLjd2vEH0i 8269VJh0rAAwGb9JiJoRILHwQnfK5O0x1qJdWMe9kxloLk+km7sPXA24Ab5FvQZ9Yqm9LEXZGl4NJ 99grsUOeJ4/32nG2p30FjQujdwAbRdtUP0Q2Gv9bAvSwTQUVQmozj6RV2hMKixR/qZOPOMhSvH9ah kTjxvFKg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHfyp-0000000Fjph-2ERn; Thu, 13 Jun 2024 08:38:47 +0000 Received: from out-178.mta0.migadu.com ([91.218.175.178]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sHfym-0000000Fjn1-2feb for linux-arm-kernel@lists.infradead.org; Thu, 13 Jun 2024 08:38:46 +0000 X-Envelope-To: shahuang@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1718267919; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Bowi7EOkTndTQt3cslYbea98TP7rJlt6kYEQxSxfRQU=; b=rCuBfqHfkguMUdlF6u8DRs0d0yksqiHxDzN0PlaV3AhxkrAUcUy96qZD4WDSx8mjOqPEX4 Jws3URRCEyxeDtGrSJeDq393+zqy++RBmNHTLS2jgV4plUQozy3596VX4auQ2kFZY3S6H1 XR2XCNV1A3JN7SyJMZKf3aMAz5N5Rxg= X-Envelope-To: maz@kernel.org X-Envelope-To: kvmarm@lists.linux.dev X-Envelope-To: eauger@redhat.com X-Envelope-To: sebott@redhat.com X-Envelope-To: cohuck@redhat.com X-Envelope-To: catalin.marinas@arm.com X-Envelope-To: james.morse@arm.com X-Envelope-To: kvm@vger.kernel.org X-Envelope-To: linux-arm-kernel@lists.infradead.org X-Envelope-To: linux-kernel@vger.kernel.org X-Envelope-To: linux-kselftest@vger.kernel.org X-Envelope-To: pbonzini@redhat.com X-Envelope-To: shuah@kernel.org X-Envelope-To: suzuki.poulose@arm.com X-Envelope-To: will@kernel.org X-Envelope-To: yuzenghui@huawei.com Date: Thu, 13 Jun 2024 01:38:33 -0700 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Shaoqin Huang Cc: Marc Zyngier , kvmarm@lists.linux.dev, 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: [RFC PATCH v1 0/2] KVM: arm64: Making BT Field in ID_AA64PFR1_EL1 writable Message-ID: References: <20240612023553.127813-1-shahuang@redhat.com> <8634pilbja.wl-maz@kernel.org> <7f1ca739-42f5-4e3a-a0c9-b1eac4522a97@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7f1ca739-42f5-4e3a-a0c9-b1eac4522a97@redhat.com> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240613_013845_070722_98D0E2C8 X-CRM114-Status: GOOD ( 31.82 ) 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 Thu, Jun 13, 2024 at 04:31:45PM +0800, Shaoqin Huang wrote: > Hi Marc, > > On 6/12/24 18:07, Marc Zyngier wrote: > > On Wed, 12 Jun 2024 06:30:51 +0100, > > Oliver Upton wrote: > > > > > > Hi Shaoqin, > > > > > > On Tue, Jun 11, 2024 at 10:35:50PM -0400, Shaoqin Huang wrote: > > > > Hi guys, > > > > > > > > I'm trying to enable migration from MtCollins(Ampere Altra, ARMv8.2+) to > > > > AmpereOne(AmpereOne, ARMv8.6+), the migration always fails when migration from > > > > MtCollins to AmpereOne due to some register fields differing between the > > > > two machines. > > > > > > > > In this patch series, we try to make more register fields writable like > > > > ID_AA64PFR1_EL1.BT. This is first step towards making the migration possible. > > > > Some other hurdles need to be overcome. This is not sufficient to make the > > > > migration successful from MtCollins to AmpereOne. > > > > > > It isn't possible to transparently migrate between these systems. The > > > former has a cntfrq of 25MHz, and the latter has a cntfrq of 1GHz. There > > > isn't a mechanism for scaling the counter frequency, and I have zero > > > appetite for a paravirt interface. > > > > Note that there *is* an architectural workaround in the form of > > FEAT_CNTSC. But of course: Heh, I should've further specified a per-CPU mechanism :) > > - it is optional (and likely not implemented) > > - it is global (hence affecting all SW running on the machine) > > - it invalidates the requirements of ARMv8.6 (who cares?) > > - KVM has nothing to do with it (yay!) > > > > So if the two systems (from the same manufacturer) were ever designed > > to allow migration between the two, they would have at least baked > > some of that in. > > > > As for the paravirt interface, I agree that this is a non-starter > > (been there, done that, dumped it in the bin). > > > > The patch itself is interesting and may be of use once it has been put > > to a compiler and not just dumped on the list without any testing. > > > > M. > > Thanks for putting your comments here. > > If we don't care about the FEAT_CNTSC right now. Could I fix the compile > issue and respin this again without the background of enabling migration > between MtCollins and AmpereOne, and just keep the information of the > different BT field between different machine? I don't think cross-platform migration is relevant for the KVM UAPI you're trying to augment. 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. So if you could focus the changelog purely as an improvement upon the existing controls we expose to the VMM then the patch is more obviously justified. Please do respin. -- Thanks, Oliver