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=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 73CD3C55191 for ; Fri, 24 Apr 2020 10:40:12 +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 23C432071E for ; Fri, 24 Apr 2020 10:40:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="fkaawp2C" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 23C432071E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject: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=VEYti35cPIak0OIiWZVDOb44YyRRHSceGkKcWLUfoHI=; b=fkaawp2CxrEBvH VsQggSuD9mxC6C2FMfRc0ZIMRobBlxaUsOEfP80oQ9rFEjUsx+MwjVzV5hThTUritsL+XYvEI7S/S hJioYtMTv8O1GDKVRULtoEf7BDnsP3fy6DuOiK2AxnREVKPoDriRkbwiVUcuCsGpA3OaRTHcBxEkZ bs2p35xW05R1hgekdGTQ/uZwRyubcbsBw4J12hb15wxRjA0iwubHDvZgd8otgAVhwcgClvs2nTis0 wXh+OLXOlVjcF91MBsR9yi0qMyLA885EDguuXERJ3zXWZJGm9na7mteI9yDkW61qpwTAIGjSEelHl Y8ZpPrl2ksrYhowSMt9A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jRvkd-0007Sm-PG; Fri, 24 Apr 2020 10:40:07 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jRvkY-0006NG-N9 for linux-arm-kernel@lists.infradead.org; Fri, 24 Apr 2020 10:40:04 +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 9ABDC1FB; Fri, 24 Apr 2020 03:40:00 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4E0C53F6CF; Fri, 24 Apr 2020 03:39:56 -0700 (PDT) Date: Fri, 24 Apr 2020 11:39:53 +0100 From: Mark Rutland To: Jianyong Wu Subject: Re: [RFC PATCH v11 5/9] psci: Add hypercall service for ptp_kvm. Message-ID: <20200424103953.GD1167@C02TD0UTHF1T.local> References: <20200421032304.26300-1-jianyong.wu@arm.com> <20200421032304.26300-6-jianyong.wu@arm.com> <20200421095736.GB16306@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-20200424_034002_859613_DF875CAA X-CRM114-Status: GOOD ( 22.95 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "maz@kernel.org" , Justin He , "kvm@vger.kernel.org" , Suzuki Poulose , "netdev@vger.kernel.org" , "richardcochran@gmail.com" , Steve Capper , "linux-kernel@vger.kernel.org" , "sean.j.christopherson@intel.com" , Steven Price , Kaly Xin , "john.stultz@linaro.org" , "yangbo.lu@nxp.com" , "pbonzini@redhat.com" , "tglx@linutronix.de" , nd , "will@kernel.org" , "kvmarm@lists.cs.columbia.edu" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Apr 24, 2020 at 03:50:22AM +0100, Jianyong Wu wrote: > On 2020/4/21 5:57 PM, Mark Rutland wrote: > > On Tue, Apr 21, 2020 at 11:23:00AM +0800, Jianyong Wu wrote: > >> diff --git a/virt/kvm/arm/hypercalls.c b/virt/kvm/arm/hypercalls.c > >> index 550dfa3e53cd..a5309c28d4dc 100644 > >> --- a/virt/kvm/arm/hypercalls.c > >> +++ b/virt/kvm/arm/hypercalls.c > >> @@ -62,6 +66,44 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu) > >> if (gpa != GPA_INVALID) > >> val = gpa; > >> break; > >> +/* > >> + * This serves virtual kvm_ptp. > >> + * Four values will be passed back. > >> + * reg0 stores high 32-bit host ktime; > >> + * reg1 stores low 32-bit host ktime; > >> + * reg2 stores high 32-bit difference of host cycles and cntvoff; > >> + * reg3 stores low 32-bit difference of host cycles and cntvoff. > >> + */ > >> +case ARM_SMCCC_HYP_KVM_PTP_FUNC_ID: > > Shouldn't the host opt-in to providing this to the guest, as with other > > features? > > er, do you mean that "ARM_SMCCC_HV_PV_TIME_XXX" as "opt-in"? if so, I > think this > > kvm_ptp doesn't need a buddy. the driver in guest will call this service > in a definite way. I mean that when creating the VM, userspace should be able to choose whether the PTP service is provided to the guest. The host shouldn't always provide it as there may be cases where doing so is undesireable. > >> +/* > >> + * system time and counter value must captured in the same > >> + * time to keep consistency and precision. > >> + */ > >> +ktime_get_snapshot(&systime_snapshot); > >> +if (systime_snapshot.cs_id != CSID_ARM_ARCH_COUNTER) > >> +break; > >> +arg[0] = upper_32_bits(systime_snapshot.real); > >> +arg[1] = lower_32_bits(systime_snapshot.real); > > Why exactly does the guest need the host's real time? Neither the cover > > letter nor this commit message have explained that, and for those of us > > unfamliar with PTP it would be very helpful to know that to understand > > what's going on. > > oh, sorry, I should have added more background knowledge here. > > just give some hints here: > > the kvm_ptp targets to sync guest time with host. some services in user > space > > like chrony can do time sync by inputing time(in kvm_ptp also clock > counter sometimes) from > > remote clocksource(often network clocksource). This kvm_ptp driver can > offer a interface for > > those user space service in guest to get the host time to do time sync > in guest. I think it would be very helpful for the commit message and/or cover letter to have a high-level desctiption of what PTP is meant to do, and an outline of the algorithmm (clearly splitting the host and guest bits). It's also not clear to me what notion of host time is being exposed to the guest (and consequently how this would interact with time changes on the host, time namespaces, etc). Having some description of that would be very helpful. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel