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 X-Spam-Level: X-Spam-Status: No, score=-14.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 67CE6C433B4 for ; Mon, 17 May 2021 13:10:53 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C94A961042 for ; Mon, 17 May 2021 13:10:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C94A961042 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; 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=JRHsoOGMH09eiZoEzuhv4MpHu0Zo7Ejp3STB1XDDgrU=; b=SmoY9CEGOUMkHRuRqqtI+xuTN H7LT0/rjU6IMRK9rOaTCucPiZGoTtBBSVeSS3au2jMgAytUP7+BKx1gNM05QUZ+3tLj4JNCkuNdCd iLrnZSWFZnkrVzB7zaHV7k76AY135SLUEK15z7u9K7bmiczQ2rmlY8gBverXLIjKPFu3nq9MetDO8 wxS2wNOvCyJb/w4Ola8QGI8C9W0HaWrLB4zbMSuVjHtCQSHIUl0jzAmSrxpRlV/3qYbt24FPRJ0nP GCMvrw2D13dCAPZGDuVE7OYEDzIN4Wtsdhiv6cnN3I9UyHWZ/RPIWePQZGzoAvZH5OPswt6kMH6kC 0sbRJg8bg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1liczI-00F0I3-5J; Mon, 17 May 2021 13:08:48 +0000 Received: from bombadil.infradead.org ([2607:7c80:54:e::133]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1licz4-00F0GM-HH for linux-arm-kernel@desiato.infradead.org; Mon, 17 May 2021 13:08:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=N0szJ7ZitSyeMRUMFJJzVdcotv+UiN0rtlPKYa/dnyQ=; b=FolVTnbCyjVL4YJsCeK1MK+a+o 6Db6bxgMQCUFyNwAp+J0pnS/+qnIBwKphrRfCD5/2yfdUZhO7ZJMb3+dkPJ7okPdLfK/GowkFCWXq Gc7LHP6PgzSLmH5zVY52UNu85GjmmkO3gURkIbAaO8EsRvZiF5yPeExkMBHU6hvgizsCA/m6Jf/pL Blm8sn1sV7JLVkd5SpBQ5k6Cy/zgix2HQC75iljqqeyGBI6XjZ6Kdfyoj9Z1DDZNqWnKgcn477aZp m93TpMLA8LhNhKJVoJibVpphUKmY0upvrB6QVUXtjMH2GWcwJGuzvVKUeELf8yDFocG1tLqz1K9Rv 2UBUmFxQ==; Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1licyy-00DmUT-DN for linux-arm-kernel@lists.infradead.org; Mon, 17 May 2021 13:08:33 +0000 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 4F6E1113E; Mon, 17 May 2021 06:08:21 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.3.85]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5D6DB3F73B; Mon, 17 May 2021 06:08:18 -0700 (PDT) Date: Mon, 17 May 2021 14:08:15 +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: <20210517130815.GC62656@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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210517_060828_573394_F2D4F4AD X-CRM114-Status: GOOD ( 40.51 ) 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 Fri, May 14, 2021 at 03:35:15PM +0000, Michael Kelley wrote: > From: Mark Rutland Sent: Friday, May 14, 2021 5:37 AM > > On Wed, May 12, 2021 at 10:37:43AM -0700, Michael Kelley wrote: > > > Add architecture specific definitions and functions needed > > > by the architecture independent Hyper-V clocksource driver. > > > Update the Hyper-V clocksource driver to be initialized > > > on ARM64. > > > > Previously we've said that for a clocksource we must use the architected > > counter, since that's necessary for things like the VDSO to work > > correctly and efficiently. > > > > Given that, I'm a bit confused that we're registering a per-cpu > > clocksource that is in part based on the architected counter. Likewise, > > I don't entirely follow why it's necessary to PV the clock_event_device. > > > > Are the architected counter and timer reliable without this PV > > infrastructure? Why do we need to PV either of those? > > > > Thanks, > > Mark. > > For the clocksource, we have a requirement to live migrate VMs > between Hyper-V hosts running on hardware that may have different > arch counter frequencies (it's not conformant to the ARM v8.6 1 GHz > requirement). The Hyper-V virtualization does scaling to handle the > frequency difference. And yes, there's a tradeoff with vDSO not > working, though we have an out-of-tree vDSO implementation that > we can use when necessary. Just to be clear, the vDSO is *one example* of something that won't function correctly. More generally, because this undermines core architectural guarantees, it requires more invasive changes (e.g. we'd have to weaken the sanity checks, and not use the counter in things like kexec paths), impacts any architectural features tied to the generic timer/counter (e.g. the event stream, SPE and tracing, future features), and means that other SW (e.g. bootloaders and other EFI applications) are unlikley to function correctly in this environment. I am very much not keen on trying to PV this. What does the guest see when it reads CNTFRQ_EL0? Does this match the real HW value (and can this change over time)? Or is this entirely synthetic? What do the ACPI tables look like in the guest? Is there a GTDT table at all? How does the counter event stream behave? Are there other architectural features which Hyper-V does not implement for a guest? Is there anything else that may change across a migration? e.g. MIDR? MPIDR? Any of the ID registers? > For clockevents, the only timer interrupt that Hyper-V provides > in a guest VM is its virtualized "STIMER" interrupt. There's no > virtualization of the ARM arch timer in the guest. I think that is rather unfortunate, given it's a core architectural feature. Is it just the interrupt that's missing? i.e. does all the PE-local functionality behave as the architecture requires? Thanks, Mark. > > > > > > > Signed-off-by: Michael Kelley > > > Reviewed-by: Sunil Muthuswamy > > > --- > > > arch/arm64/include/asm/mshyperv.h | 12 ++++++++++++ > > > drivers/clocksource/hyperv_timer.c | 14 ++++++++++++++ > > > 2 files changed, 26 insertions(+) > > > > > > diff --git a/arch/arm64/include/asm/mshyperv.h b/arch/arm64/include/asm/mshyperv.h > > > index c448704..b17299c 100644 > > > --- a/arch/arm64/include/asm/mshyperv.h > > > +++ b/arch/arm64/include/asm/mshyperv.h > > > @@ -21,6 +21,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > /* > > > * Declare calls to get and set Hyper-V VP register values on ARM64, which > > > @@ -41,6 +42,17 @@ static inline u64 hv_get_register(unsigned int reg) > > > return hv_get_vpreg(reg); > > > } > > > > > > +/* Define the interrupt ID used by STIMER0 Direct Mode interrupts. This > > > + * value can't come from ACPI tables because it is needed before the > > > + * Linux ACPI subsystem is initialized. > > > + */ > > > +#define HYPERV_STIMER0_VECTOR 31 > > > + > > > +static inline u64 hv_get_raw_timer(void) > > > +{ > > > + return arch_timer_read_counter(); > > > +} > > > + > > > /* SMCCC hypercall parameters */ > > > #define HV_SMCCC_FUNC_NUMBER 1 > > > #define HV_FUNC_ID ARM_SMCCC_CALL_VAL( \ > > > diff --git a/drivers/clocksource/hyperv_timer.c b/drivers/clocksource/hyperv_timer.c > > > index 977fd05..270ad9c 100644 > > > --- a/drivers/clocksource/hyperv_timer.c > > > +++ b/drivers/clocksource/hyperv_timer.c > > > @@ -569,3 +569,17 @@ void __init hv_init_clocksource(void) > > > hv_setup_sched_clock(read_hv_sched_clock_msr); > > > } > > > EXPORT_SYMBOL_GPL(hv_init_clocksource); > > > + > > > +/* Initialize everything on ARM64 */ > > > +static int __init hyperv_timer_init(struct acpi_table_header *table) > > > +{ > > > + if (!hv_is_hyperv_initialized()) > > > + return -EINVAL; > > > + > > > + hv_init_clocksource(); > > > + if (hv_stimer_alloc(true)) > > > + return -EINVAL; > > > + > > > + return 0; > > > +} > > > +TIMER_ACPI_DECLARE(hyperv, ACPI_SIG_GTDT, hyperv_timer_init); > > > -- > > > 1.8.3.1 > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel