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 B6F29C64EC4 for ; Wed, 8 Mar 2023 07:47:08 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Yx/bZjXit3htqMDGyiGAg6Jr0LE1PyHF35lHku1Ctac=; b=AIltB1onqn6gRI /Iy61nE4vHtS+arJr6DinqJmpxw/G4pPj5v8nmefNiwIf19LEJCJR76eQ2i5trSw0957jxYC5UUH9 wXHxAbn5z4DYNvWBy9dJTWsCROcNAl/yQW/mVj+MjXM7WmKdKHxdIO3P+TD3aXkPRX6/moIGaH0L0 TGoo4SxYdYrHpvJqHrKgjSOwODEr2KANzTITra6/S7TV7g/ZqosDjrRP111af8G7Zjo9/nxOsP/FD rOC+j2q8rlVGh+3klcJW/UijMPUh7Z+5nZANytzr9OqR//t5c3kQ0uuGc6s7vx3glmHRTmd6PeMu9 ljQzbILQ+oUlKDuSsVow==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pZoV2-003qLX-W4; Wed, 08 Mar 2023 07:46:13 +0000 Received: from out-63.mta0.migadu.com ([2001:41d0:1004:224b::3f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pZoUy-003qJp-Iz for linux-arm-kernel@lists.infradead.org; Wed, 08 Mar 2023 07:46:11 +0000 Date: Wed, 8 Mar 2023 07:46:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1678261565; 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=WKzyZZ5TvHHv+nFcORL1XTaFGVCC5mIp3QEkslOGjpM=; b=pecnibry7D0AwevOwIcO8UrAJTSKX40E+DlEkvW+GKrHUO3XhEWYK89YgKhyyDma0I3nlW +8aMPyy+tAec1ZV/rmxDkbLBB36GwHf2BGoHVGo2SjoNI/TWgors07Tv1PU/Zit5+xS3ux rQpO1uuv/KwLWBboGjF3wDl7r2NSC5U= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Marc Zyngier Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, James Morse , Suzuki K Poulose , Zenghui Yu , Ricardo Koller , Simon Veith , dwmw2@infradead.org Subject: Re: [PATCH 08/16] KVM: arm64: timers: Allow userspace to set the counter offsets Message-ID: References: <20230216142123.2638675-1-maz@kernel.org> <20230216142123.2638675-9-maz@kernel.org> <86k00gy4so.wl-maz@kernel.org> <86bkllyku2.wl-maz@kernel.org> <867cw8xmq2.wl-maz@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <867cw8xmq2.wl-maz@kernel.org> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230307_234609_058885_05890793 X-CRM114-Status: GOOD ( 29.64 ) 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 Hey Marc, On Thu, Feb 23, 2023 at 06:25:57PM +0000, Marc Zyngier wrote: [...] > > Do we need to bend over backwards for a theoretical use case with > > the new UAPI? If anyone depends on the existing behavior then they can > > continue to use the old UAPI to partially migrate the guest counters. > > I don't buy the old/new thing. My take is that these things should be > cumulative if there isn't a hard reason to break the existing API. Unsurprisingly, I may have been a bit confusing in my replies to you. I have zero interest in breaking the existing API. Any suggestion of 'changing the rules' was more along the lines of providing an alternate scheme for the counters and letting the quirks of the old interface continue. > > My previous suggestion of tying the physical and virtual counters > > together at VM creation would definitely break such a use case, though, > > so we'd be at the point of requiring explicit opt-in from userspace. > > I'm trying to find a middle ground, so bear with me. Here's the > situation as I see it: > > (1) a VM that is migrating today can only set the virtual offset and > doesn't affect the physical counter. This behaviour must be > preserved in we cannot prove that nobody relies on it. > > (2) setting the physical offset could be done by two means: > > (a) writing the counter register (like we do for CNTVCT) > (b) providing an offset via a side channel > > I think (1) must stay forever, just like we still support the old > GICv2 implicit initialisation. No argument here. Unless userspace pokes some new bit of UAPI, the old behavior of CNTVCT must live on. > (2a) is also desirable as it requires no extra work on the VMM side. > Just restore the damn thing, and nothing changes (we're finally able > to migrate the physical timer). (2b) really is icing on the cake. > > The question is whether we can come up with an API offering (2b) that > still allows (1) and (2a). I'd be happy with a new API that, when > used, resets both offsets to the same value, matching your pretty > picture. But the dual offsetting still has to exist internally. > > When it comes to NV, it uses either the physical offset that has been > provided by writing CNTPCT, or the one that has been written via the > new API. Under the hood, this is the same piece of data, of course. > > The only meaningful difference with my initial proposal is that there > is no new virtual offset API. It is either register writes that obey > the same rules as before, or a single offset setting. I certainly agree that (2a) is highly desirable to get existing VMMs to 'do the right thing' for free. Playing devil's advocate, would this not also break the tracing example you've given of correlating timestamps between the host and guest? I wouldn't expect a userspace + VM tracing contraption to live migrate but restoring from a snapshot seems plausible. Regardless, I like the general direction you've proposed. IIUC, you'll want to go ahead with ignoring writes to CNT{P,V}CT if the offset was written by userspace, right? -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel