Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp667967pxj; Thu, 10 Jun 2021 09:47:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwr8SKKsHDDnvaimZoz9O7rT0lfXMQg/ln9ySlyGvKMechJzwQI8vZ3QltdDDl0gRo9Xz7r X-Received: by 2002:aa7:d14d:: with SMTP id r13mr409217edo.212.1623343649700; Thu, 10 Jun 2021 09:47:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623343649; cv=none; d=google.com; s=arc-20160816; b=ofGYe3fBDdfQfNKXUp6Lr8Oe+2D9xOAOVb60RxUmg2uyPJ9ujLF9qNwLmXlWHmbCLT QCCGzNNOsKuRcYi33qdwbvz9g8mkx6rjSf5Q+ITpAqkbDA1IMewRXvZEJIu5km8ntlPJ 2aeOLLw7YRWGbv/NpkzFiLU1akJlXUvkcRq4uBvyX9qn8mIvKB0dbcWuw0HfhQsfpKDq cGh4UOV9E73MXo3TNLgyl4fg9X2hgS0K7XBQiM9mfXHVy13wp0cKzQpJlwOPg34gPly5 tlHMvm95B7KkbOaiT1Aq5Q4mWM60IHFo3F4vf2hjaIBIZwo2QyvkNmu5Zhmdn64z/pfm lHWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=KAtdh556o39qColfZUNjBMOXZrW7WMyga1bfsgmiNik=; b=CVDwccjCCcfnhoz5USOJnlzTwwqTwHaT1/8RRwsbRHJCSNO5ioXE7SZHU8nSMC7lGt 5k1Q8TNmR0blLM3niLd9Xa+EikkCbdAjOBPYBYeRLrTy5fxYuOq4M5q4i9zndOuqQfZ2 5GoIiW25MbwHNTTKPuzwsXJ+QOeRaCfsBTgccghktGXitPSWGQhXRf2B9IXCxNQKCZ8R c30Hhbhrft3BT9TXgaGfCNs1LSvMx9zigK63/Fd6W3niRzqxUwv19XMKkwUmlg/hmQ3/ 4xFUltEIS6taeS0gVVuyWVyvESF4CchHwN1FhxHILHLRb/EV/ZiWxrN9jj7j29rwhNbO 0Drg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y5si2486070edv.563.2021.06.10.09.47.06; Thu, 10 Jun 2021 09:47:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231341AbhFJQrV (ORCPT + 99 others); Thu, 10 Jun 2021 12:47:21 -0400 Received: from foss.arm.com ([217.140.110.172]:36630 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230396AbhFJQrU (ORCPT ); Thu, 10 Jun 2021 12:47:20 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 45919ED1; Thu, 10 Jun 2021 09:45:24 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.7.234]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 0F4F13F719; Thu, 10 Jun 2021 09:45:21 -0700 (PDT) Date: Thu, 10 Jun 2021 17:45:19 +0100 From: Mark Rutland To: Michael Kelley Cc: "will@kernel.org" , "catalin.marinas@arm.com" , "lorenzo.pieralisi@arm.com" , "sudeep.holla@arm.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-hyperv@vger.kernel.org" , "linux-efi@vger.kernel.org" , "arnd@arndb.de" , "wei.liu@kernel.org" , "ardb@kernel.org" , "daniel.lezcano@linaro.org" , KY Srinivasan Subject: Re: [PATCH v10 3/7] arm64: hyperv: Add Hyper-V clocksource/clockevent support Message-ID: <20210610164519.GB63335@C02TD0UTHF1T.local> References: <1620841067-46606-1-git-send-email-mikelley@microsoft.com> <1620841067-46606-4-git-send-email-mikelley@microsoft.com> <20210514123711.GB30645@C02TD0UTHF1T.local> <20210517130815.GC62656@C02TD0UTHF1T.local> <20210518170016.GP82842@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Michael, [trimming the bulk of the thrread] On Tue, Jun 08, 2021 at 03:36:06PM +0000, Michael Kelley wrote: > I've had a couple rounds of discussions with the Hyper-V team. For > the clocksource we've agreed to table the live migration discussion, and > I'll resubmit the code so that arm_arch_timer.c provides the > standard arch_sys_counter clocksource. As noted previously, this just > works for a Hyper-V guest. The live migration discussion may come > back later after a deeper investigation by Hyper-V. Great; thanks for this! > For clockevents, there's not a near term fix. It's more than just plumbing > an interrupt for Hyper-V to virtualize the ARM64 arch timer in a guest VM. > From their perspective there's also benefit in having a timer abstraction > that's independent of the architecture, and in the Linux guest, the STIMER > code is common across x86/x64 and ARM64. It follows the standard Linux > clockevents model, as it should. The code is already in use in out-of-tree > builds in the Linux VMs included in Windows 10 on ARM64 as part of the > so-called "Windows Subsystem for Linux". > > So I'm hoping we can get this core support for ARM64 guests on Hyper-V > into upstream using the existing STIMER support. At some point, Hyper-V > will do the virtualization of the ARM64 arch timer, but we don't want to > have to stay out-of-tree until after that happens. My main concern here is making sure that we can rely on architected properties, and don't have to special-case architected bits for hyperv (or any other hypervisor), since that inevitably causes longer-term pain. While in abstract I'm not as worried about using the timer clock_event_device specifically, that same driver provides the clocksource and the event stream, and I want those to work as usual, without being tied into the hyperv code. IIUC that will require some work, since the driver won't register if the GTDT is missing timer interrupts (or if there is no GTDT). I think it really depends on what that looks like. Thanks, Mark.