From patchwork Fri Sep 4 09:27:43 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jianyong Wu X-Patchwork-Id: 11756417 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 1DE27109A for ; Fri, 4 Sep 2020 09:30:23 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 E805920791 for ; Fri, 4 Sep 2020 09:30:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="wz9WgqCB" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E805920791 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+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:MIME-Version:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:References:In-Reply-To:Message-Id:Date:Subject:To: From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ld7pYophnnUvKbW2/5YN/y4cN7HJvKTviyBpr+vh8WE=; b=wz9WgqCBROzn7leyPm9JROZJ6J dBWhfmTbgapQFW8Xasw01DEG8LAzZ9onCAQuKD/vo+6s6qZGZRz83BO15AsK9s2CMhDhFirzImJkn VL+wO/S94mj+ghwjKVJRckGAQXAvU9ALhaTxyO1I4eiPsBqYc/lypj5gnRWkNUxYdUE4pdd6Sj5uM k9GhI6mSvkk5/ZD3/4HIPVGifP8g0D3Ij0gwBy8qPdQNlWiSZP0sCB0eFyw1BdrkcuHR6ixQaw66X I+wOf4cozUN/KdXenYXPe8FjVAYD+SsEu6RYQhv8SGis9satPt/5e+rJ0dq78Jo2b+gGaoHt9wUuC AUIwPP1A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kE82s-00007r-Sh; Fri, 04 Sep 2020 09:30:10 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kE82c-0008Rf-OG for linux-arm-kernel@lists.infradead.org; Fri, 04 Sep 2020 09:29:57 +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 06945152D; Fri, 4 Sep 2020 02:29:54 -0700 (PDT) Received: from localhost.localdomain (entos-thunderx2-desktop.shanghai.arm.com [10.169.212.215]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 545743F66F; Fri, 4 Sep 2020 02:29:48 -0700 (PDT) From: Jianyong Wu To: netdev@vger.kernel.org, yangbo.lu@nxp.com, john.stultz@linaro.org, tglx@linutronix.de, pbonzini@redhat.com, sean.j.christopherson@intel.com, maz@kernel.org, richardcochran@gmail.com, Mark.Rutland@arm.com, will@kernel.org, suzuki.poulose@arm.com, steven.price@arm.com Subject: [PATCH v14 09/10] doc: add ptp_kvm introduction for arm64 support Date: Fri, 4 Sep 2020 17:27:43 +0800 Message-Id: <20200904092744.167655-10-jianyong.wu@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200904092744.167655-1-jianyong.wu@arm.com> References: <20200904092744.167655-1-jianyong.wu@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200904_052954_900468_F8FFB67A X-CRM114-Status: GOOD ( 19.37 ) X-Spam-Score: -2.3 (--) X-Spam-Report: SpamAssassin version 3.4.4 on merlin.infradead.org summary: Content analysis details: (-2.3 points) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [217.140.110.172 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 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: justin.he@arm.com, kvm@vger.kernel.org, Steve.Capper@arm.com, jianyong.wu@arm.com, linux-kernel@vger.kernel.org, nd@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org ptp_kvm implementation depends on hypercall using SMCCC. So we introduce a new SMCCC service ID. This doc explain how we define and use this new ID. Signed-off-by: Jianyong Wu --- Documentation/virt/kvm/arm/ptp_kvm.rst | 72 ++++++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 Documentation/virt/kvm/arm/ptp_kvm.rst diff --git a/Documentation/virt/kvm/arm/ptp_kvm.rst b/Documentation/virt/kvm/arm/ptp_kvm.rst new file mode 100644 index 000000000000..455591e2587a --- /dev/null +++ b/Documentation/virt/kvm/arm/ptp_kvm.rst @@ -0,0 +1,72 @@ +.. SPDX-License-Identifier: GPL-2.0 + +PTP_KVM support for arm64 +========================= + +PTP_KVM is used for time sync between guest and host in a high precison. +It needs get wall time and counter value from host and transfer these data +to guest via hypercall service. So one more hypercall service should be +added. + +This new SMCCC hypercall will be defined as: + +* ARM_SMCCC_HYP_KVM_PTP_FUNC_ID: 0xC6000001 + +As we only support 64-bits ptp_kvm client, so we choose SMC64/HVC64 +calling convention. + +ARM_SMCCC_HYP_KVM_PTP_FUNC_ID: + + ============ ======== ========== + Function ID: (uint32) 0xC6000001 + Arguments: (uint32) ARM_PTP_PHY_COUNTER(1) or ARM_PTP_VIRT_COUNTER(0) + which indicate acquiring physical counter or + virtual counter respectively. + return value: (uint64) NOT_SUPPORTED (-1) or two values of wall clock + time and counter cycle. + ============ ======== ========== + +Why we need PTP_KVM? +Currently, we offen use ntp (sync time with remote network clock) to sync time +in VM. But the precision of ntp is subject to network delay so it's difficult +to sync time in a high precision. + +kvm virtual ptp clock (ptp_kvm) offers another way to sync time in VM, in which +the remote clock locates in the host instead of remote network clock. It +targets to sync time between guest and host in virtualization environment and +in this way, we can also keep the time of all the VMs running in the same host +in sync. In general, the delay of communication between host and guest is quiet +small, so ptp_kvm can offer time sync precision up to in order of nanosecond. +Please keep in mind that ptp_kvm just limits itself to be a channel which +transmit the remote clock from host to guest and leaves the time sync jobs to +an application, eg. chrony, in usersapce of VM. + +How PTP_KVM works on arm64? +After ptp_kvm initialized, there will be a new device node under /dev called +ptp%d. A guest userspace service, like chrony, can use this device to get host +walltime, sometimes also counter cycle, which depends on the service it calls. +Then this guest userspace service can use those data to do the time sync for +guest. +Here is a rough sketch to show how kvm ptp clock works. + +|----------------------------| |--------------------------| +| guest userspace | | host | +|ioctl -> /dev/ptp%d | | | +| ^ | | | | +|----------------------------| | | +| | | guest kernel | | | +| | V (get host walltime/counter cycle) | +| ptp_kvm -> hypercall - - - - - - - - - - ->hypercall service | +| <- - - - - - - - - - - - | +|----------------------------| |--------------------------| + +1. time sync service in guest userspace call ptp device through /dev/ptp%d. +2. ptp_kvm module in guest recive this request then invoke hypercall to + route into host kernel to request host walltime/counter cycle. +3. ptp_kvm hypercall service in host response to the request and send data + back. +4. ptp (not ptp_kvm, ptp_kvm implemented on it and not shown above) in guest + copy the data to userspace. + +This ptp_kvm implementation focuses itself to step 2 and 3 and step 2 works +in guest comparing step 3 works in host kernel.