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.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 90622C4338F for ; Wed, 11 Aug 2021 15:24:56 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 4D2FF60F11 for ; Wed, 11 Aug 2021 15:24:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4D2FF60F11 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org 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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=+Tljs65v11/WVmgOHff/sVAFZ9PI6T1AW0PLuFnj9h8=; b=ijHODB/2zqBHnA FgYoQpIKhmZnIPulMf9sFRJUQX2xPEWlW40aQiWcBp4nfsDOskVfu12Nj7cBH025rLoVC2VaWLI18 24z94L1FZgDgH+vsy9nvZpQxsWMO9Qb9t/KjR/7kXyGDM18Pl06k+ozcmeZVm+zO2A2HieVj0Ul4q +f+VgV2MLmECNXM5BKynFerRz1Q8j0pbXvlCK6xAPO8QM4J6sfrxQIwItjpuFXb+DTrP+AJZK9w/6 leg4ZjYS3jeSypeSmHlREF625unMaWXgz0GRu/5RhsZhfzoKzB1H2aSaYAXKf6TatMV47hCF8bYs0 7TkEpiyEtKYeXoAFzUQw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mDq4A-007XVt-Dg; Wed, 11 Aug 2021 15:22:50 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mDq46-007XVE-EL for linux-arm-kernel@lists.infradead.org; Wed, 11 Aug 2021 15:22:48 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C145560F11; Wed, 11 Aug 2021 15:22:45 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mDq43-004Mfn-Kz; Wed, 11 Aug 2021 16:22:43 +0100 Date: Wed, 11 Aug 2021 16:22:43 +0100 Message-ID: <87h7fw9fb0.wl-maz@kernel.org> From: Marc Zyngier To: Oliver Upton Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, Paolo Bonzini , Sean Christopherson , Peter Shier , Jim Mattson , David Matlack , Ricardo Koller , Jing Zhang , Raghavendra Rao Anata , James Morse , Alexandru Elisei , Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, Andrew Jones , Will Deacon , Catalin Marinas Subject: Re: [PATCH v6 13/21] KVM: arm64: Allow userspace to configure a vCPU's virtual offset In-Reply-To: References: <20210804085819.846610-1-oupton@google.com> <20210804085819.846610-14-oupton@google.com> <87czqlbq15.wl-maz@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: oupton@google.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, pbonzini@redhat.com, seanjc@google.com, pshier@google.com, jmattson@google.com, dmatlack@google.com, ricarkol@google.com, jingzhangos@google.com, rananta@google.com, james.morse@arm.com, Alexandru.Elisei@arm.com, suzuki.poulose@arm.com, linux-arm-kernel@lists.infradead.org, drjones@redhat.com, will@kernel.org, catalin.marinas@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210811_082246_567715_35EBF359 X-CRM114-Status: GOOD ( 35.89 ) 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 Tue, 10 Aug 2021 10:44:01 +0100, Oliver Upton wrote: > > On Tue, Aug 10, 2021 at 2:35 AM Marc Zyngier wrote: > > > > On Wed, 04 Aug 2021 09:58:11 +0100, > > Oliver Upton wrote: > > > > > > Allow userspace to access the guest's virtual counter-timer offset > > > through the ONE_REG interface. The value read or written is defined to > > > be an offset from the guest's physical counter-timer. Add some > > > documentation to clarify how a VMM should use this and the existing > > > CNTVCT_EL0. > > > > > > Signed-off-by: Oliver Upton > > > --- > > > Documentation/virt/kvm/api.rst | 10 ++++++++++ > > > arch/arm64/include/uapi/asm/kvm.h | 1 + > > > arch/arm64/kvm/arch_timer.c | 11 +++++++++++ > > > arch/arm64/kvm/guest.c | 6 +++++- > > > include/kvm/arm_arch_timer.h | 1 + > > > 5 files changed, 28 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst > > > index 8d4a3471ad9e..28a65dc89985 100644 > > > --- a/Documentation/virt/kvm/api.rst > > > +++ b/Documentation/virt/kvm/api.rst > > > @@ -2487,6 +2487,16 @@ arm64 system registers have the following id bit patterns:: > > > derived from the register encoding for CNTV_CVAL_EL0. As this is > > > API, it must remain this way. > > > > > > +.. warning:: > > > + > > > + The value of KVM_REG_ARM_TIMER_OFFSET is defined as an offset from > > > + the guest's view of the physical counter-timer. > > > + > > > + Userspace should use either KVM_REG_ARM_TIMER_OFFSET or > > > + KVM_REG_ARM_TIMER_CVAL to pause and resume a guest's virtual > > > > You probably mean KVM_REG_ARM_TIMER_CNT here, despite the broken > > encoding. > > Indeed I do! > > > > > > + counter-timer. Mixed use of these registers could result in an > > > + unpredictable guest counter value. > > > + > > > arm64 firmware pseudo-registers have the following bit pattern:: > > > > > > 0x6030 0000 0014 > > > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h > > > index b3edde68bc3e..949a31bc10f0 100644 > > > --- a/arch/arm64/include/uapi/asm/kvm.h > > > +++ b/arch/arm64/include/uapi/asm/kvm.h > > > @@ -255,6 +255,7 @@ struct kvm_arm_copy_mte_tags { > > > #define KVM_REG_ARM_TIMER_CTL ARM64_SYS_REG(3, 3, 14, 3, 1) > > > #define KVM_REG_ARM_TIMER_CVAL ARM64_SYS_REG(3, 3, 14, 0, 2) > > > #define KVM_REG_ARM_TIMER_CNT ARM64_SYS_REG(3, 3, 14, 3, 2) > > > +#define KVM_REG_ARM_TIMER_OFFSET ARM64_SYS_REG(3, 4, 14, 0, 3) > > > > I don't think we can use the encoding for CNTPOFF_EL2 here, as it will > > eventually clash with a NV guest using the same feature for its own > > purpose. We don't want this offset to overlap with any of the existing > > features. > > > > I actually liked your previous proposal of controlling the physical > > offset via a device property, as it clearly indicated that you were > > dealing with non-architectural state. > > That's actually exactly what I did here :) That said, the macro name > is horribly obfuscated from CNTVOFF_EL2. I did this for the sake of > symmetry with other virtual counter-timer registers above, though this > may warrant special casing given the fact that we have a similarly > named device attribute to handle the physical offset. Gah, you are of course right. Ignore my rambling. The name is fine (or at least in keeping with existing quality level of the making). For the physical offset, something along the lines of KVM_ARM_VCPU_TIMER_PHYS_OFFSET is probably right (but feel free to be creative, I'm terrible at this stuff [1]). Thanks, M. [1] https://twitter.com/codinghorror/status/506010907021828096?lang=en -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel