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 A15A6C05027 for ; Mon, 6 Feb 2023 19:56:26 +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=tuPltQ87i91TKm+NNOygLY2qQn3cz/mJNRw+dXJRFL4=; b=CAWgNTHhKQ6Txx w4HguxWIr0hD9yVw++TYT6VeF8+dgHc5PWZtVxf7Py19VdtsdrqHI3hxpd/punSCLi6pgFPAT8Y+Y QAK94crEz7IgeNeUENR1v5gVt3E8+LA3kxbjUz8es5oL0ajdZ1OooijMbqnSEpzFy8DE7cXgCSpzw AwwOLGvlPb/nEBMcGcNL+TIjUR3JtboVMtrbXAjtqz0JVLlb9NxxMO0DXrcPh0CJyAHCf/Fv3AFdB tsgsDoMfzA3MKZPzR7addXQCdkE0FQX8DrDMPd9ZIXxKiMLJ8FK7mtZ4XgxL5ajEl3s7DOjeYTVBE DgO2QR4Rqgerv2jCGZ6g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pP7aR-009lbI-BP; Mon, 06 Feb 2023 19:55:35 +0000 Received: from out-241.mta1.migadu.com ([95.215.58.241]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pP7aO-009la5-Hl for linux-arm-kernel@lists.infradead.org; Mon, 06 Feb 2023 19:55:34 +0000 Date: Mon, 6 Feb 2023 19:55:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1675713328; 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=v9bnPc0+jnaByE6IN7UeGxfdWZNIB9vqvQe6tkJz/4Q=; b=Er+JrR/3/nRSFJd79x9rLoKcO8QPjl7OGjSUhYFIghPgvtpm4TrgeENwT7j+7PGyyedwSJ plw5iFGTLx5cnJYPZjKXP/HQ0YBt6AyxMNV8z6yHc9DKAQEXxCzRVOG5mCqqfEHKzueB/j 4i6+FpD8sbtLkPJPLJapa/DwRXoWKh8= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: David Woodhouse Cc: Marc Zyngier , Simon Veith , Catalin Marinas , Will Deacon , James Morse , Suzuki K Poulose , Zenghui Yu , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] arm64: kvm: Expose timer offset directly via KVM_{GET,SET}_ONE_REG Message-ID: References: <20230202121314.206195-1-sveith@amazon.de> <86a61w18hp.wl-maz@kernel.org> <903da8727680b394a645b81ce9dcdf25354138b0.camel@infradead.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <903da8727680b394a645b81ce9dcdf25354138b0.camel@infradead.org> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230206_115532_761805_5F27DEDC X-CRM114-Status: GOOD ( 18.40 ) 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 On Thu, Feb 02, 2023 at 03:18:55PM +0000, David Woodhouse wrote: > On Thu, 2023-02-02 at 13:50 +0000, Marc Zyngier wrote: > > On Thu, 02 Feb 2023 12:13:14 +0000, Simon Veith wrote: [...] > > > The issue is further complicated when vCPU setup is performed by > > > independent threads which may experience different delays, leading to > > > jitter between the clocks of different vCPUs. > > > > How? I really hope that you will have restored *all* the vcpus before > > restarting any. If you don't, your userspace is buggy. > > But the timer counts from the epoch of when the KVM itself was > initialised, doesn't it? I haven't looked hard at the arm side but on > x86 if the various vCPU threads all use the "TSC is now" API, they > only end up in sync because there's a hack for "if it's within one > second of the previously-set vCPU's TSC, make it precisely match". And > then they're only in sync with each *other* rather than what they were > before the live update. We don't have any analog to the x86 TSC synchronization game on arm64. The UAPI we have relies strictly on the architecture, which effectively states that all PEs in a system have a consistent view of the generic counter. As it relates to KVM, whenever the virtual counter value is written from userspace, we apply the calculated offset to all vCPUs in the VM. And yes, this results in some wasted cycles doing this broadcast from every single vCPU. But oh well, it hasn't been consequential (yet). -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel