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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1690CC433F5 for ; Fri, 19 Nov 2021 12:18:41 +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 CBC0C613A3 for ; Fri, 19 Nov 2021 12:18:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CBC0C613A3 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=bQiQ05nBur/nGFE+o3A4PsIuzzFDM5FJ1mmJps0ailA=; b=qKYYxZ96a/ARLi ky8vEhjrcTjxD4Hn1OpLjW0UNDOZaOTGlfEMzVU1wjP/ql4qWi1/Pir++ChV1sNq4x+fLvoTbnadr Xp4fMrS2/KIEdpqhSTaa39pVWgE6lkldyNdtq0IIVf+P9w2YgES389nag6Ff2UYN3ukRL1wnv0L5A 2P8Gi1Z28uB3UqjDbN9uf1N2hm6NClOKYKs+reg49RWW391diWjVoZ5iIQDvhhjeOqEJVsBxCoXTv qBR0KzRfnsXANJn5IUTDfDQXnRqFyRMQ4J35z5jqKtNv3Q5rSGij1wq9mCsWKzxnTXwWT5iGad/E0 Zf06+b+713Sk8+N5oyUA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mo2pH-00AMf2-Ls; Fri, 19 Nov 2021 12:17:07 +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 1mo2pE-00AMee-4v for linux-arm-kernel@lists.infradead.org; Fri, 19 Nov 2021 12:17:05 +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 8BA7F61A7D; Fri, 19 Nov 2021 12:17:03 +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 1mo2pB-006XWO-CB; Fri, 19 Nov 2021 12:17:01 +0000 Date: Fri, 19 Nov 2021 12:17:00 +0000 Message-ID: <87fsrs732b.wl-maz@kernel.org> From: Marc Zyngier To: Nicolas Saenz Julienne Cc: linux-arm-kernel@lists.infradead.org, rostedt@goodmis.org, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu, mingo@redhat.com, mtosatti@redhat.com, nilal@redhat.com Subject: Re: [RFC PATCH 2/2] KVM: arm64: export cntvoff in debugfs In-Reply-To: <20211119102117.22304-3-nsaenzju@redhat.com> References: <20211119102117.22304-1-nsaenzju@redhat.com> <20211119102117.22304-3-nsaenzju@redhat.com> 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: nsaenzju@redhat.com, linux-arm-kernel@lists.infradead.org, rostedt@goodmis.org, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, will@kernel.org, linux-kernel@vger.kernel.org, kvmarm@lists.cs.columbia.edu, mingo@redhat.com, mtosatti@redhat.com, nilal@redhat.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-20211119_041704_259042_FD542C07 X-CRM114-Status: GOOD ( 30.04 ) 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, 19 Nov 2021 10:21:18 +0000, Nicolas Saenz Julienne wrote: > > While using cntvct as the raw clock for tracing, it's possible to > synchronize host/guest traces just by knowing the virtual offset applied > to the guest's virtual counter. > > This is also the case on x86 when TSC is available. The offset is > exposed in debugfs as 'tsc-offset' on a per vcpu basis. So let's > implement the same for arm64. How does this work with NV, where the guest hypervisor is in control of the virtual offset? How does userspace knows which vcpu to pick so that it gets the right offset? I also wonder why we need this when userspace already has direct access to that information without any extra kernel support (read the CNTVCT view of the vcpu using the ONEREG API, subtract it from the host view of the counter, job done). > > Signed-off-by: Nicolas Saenz Julienne > --- > arch/arm64/include/asm/kvm_host.h | 1 + > arch/arm64/kvm/Makefile | 2 +- > arch/arm64/kvm/arch_timer.c | 2 +- > arch/arm64/kvm/debugfs.c | 25 +++++++++++++++++++++++++ > include/kvm/arm_arch_timer.h | 3 +++ > 5 files changed, 31 insertions(+), 2 deletions(-) > create mode 100644 arch/arm64/kvm/debugfs.c > > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h > index 2a5f7f38006f..130534c9079e 100644 > --- a/arch/arm64/include/asm/kvm_host.h > +++ b/arch/arm64/include/asm/kvm_host.h > @@ -29,6 +29,7 @@ > #include > > #define __KVM_HAVE_ARCH_INTC_INITIALIZED > +#define __KVM_HAVE_ARCH_VCPU_DEBUGFS > > #define KVM_HALT_POLL_NS_DEFAULT 500000 > > diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile > index 989bb5dad2c8..17be7cf770f2 100644 > --- a/arch/arm64/kvm/Makefile > +++ b/arch/arm64/kvm/Makefile > @@ -14,7 +14,7 @@ kvm-y := $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o $(KVM)/eventfd.o \ > $(KVM)/vfio.o $(KVM)/irqchip.o $(KVM)/binary_stats.o \ > arm.o mmu.o mmio.o psci.o perf.o hypercalls.o pvtime.o \ > inject_fault.o va_layout.o handle_exit.o \ > - guest.o debug.o reset.o sys_regs.o \ > + guest.o debug.o debugfs.o reset.o sys_regs.o \ > vgic-sys-reg-v3.o fpsimd.o pmu.o \ > arch_timer.o trng.o\ > vgic/vgic.o vgic/vgic-init.o \ > diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c > index 3df67c127489..ee69387f7fb6 100644 > --- a/arch/arm64/kvm/arch_timer.c > +++ b/arch/arm64/kvm/arch_timer.c > @@ -82,7 +82,7 @@ u64 timer_get_cval(struct arch_timer_context *ctxt) > } > } > > -static u64 timer_get_offset(struct arch_timer_context *ctxt) > +u64 timer_get_offset(struct arch_timer_context *ctxt) > { > struct kvm_vcpu *vcpu = ctxt->vcpu; > > diff --git a/arch/arm64/kvm/debugfs.c b/arch/arm64/kvm/debugfs.c > new file mode 100644 > index 000000000000..f0f5083ea8d4 > --- /dev/null > +++ b/arch/arm64/kvm/debugfs.c > @@ -0,0 +1,25 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (C) 2021 Red Hat Inc. > + */ > + > +#include > +#include > + > +#include > + > +static int vcpu_get_cntv_offset(void *data, u64 *val) > +{ > + struct kvm_vcpu *vcpu = (struct kvm_vcpu *)data; > + > + *val = timer_get_offset(vcpu_vtimer(vcpu)); > + > + return 0; > +} > + > +DEFINE_SIMPLE_ATTRIBUTE(vcpu_cntvoff_fops, vcpu_get_cntv_offset, NULL, "%lld\n"); > + > +void kvm_arch_create_vcpu_debugfs(struct kvm_vcpu *vcpu, struct dentry *debugfs_dentry) > +{ > + debugfs_create_file("cntvoff", 0444, debugfs_dentry, vcpu, &vcpu_cntvoff_fops); > +} This should be left in arch_timer.c until we actually need it for multiple subsystems. When (and if) that happens, we will expose per-subsystem debugfs initialisers instead of exposing the guts of the timer code. Thanks, M. -- 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