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=-13.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT 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 B3BC1C2BC84 for ; Fri, 4 Sep 2020 09:30:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8BB0E20770 for ; Fri, 4 Sep 2020 09:30:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730253AbgIDJaC (ORCPT ); Fri, 4 Sep 2020 05:30:02 -0400 Received: from foss.arm.com ([217.140.110.172]:46948 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730228AbgIDJ3z (ORCPT ); Fri, 4 Sep 2020 05:29:55 -0400 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 Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Steve.Capper@arm.com, justin.he@arm.com, jianyong.wu@arm.com, nd@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> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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. -- 2.17.1 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=-13.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham 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 C6972C28E83 for ; Fri, 4 Sep 2020 09:29:58 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 7F06420791 for ; Fri, 4 Sep 2020 09:29:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F06420791 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 387E84B2A0; Fri, 4 Sep 2020 05:29:58 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44R7PNzJHnf9; Fri, 4 Sep 2020 05:29:56 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id D9D3E4B17A; Fri, 4 Sep 2020 05:29:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 901EC4B37A for ; Fri, 4 Sep 2020 05:29:55 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CG7n7LC6C19t for ; Fri, 4 Sep 2020 05:29:54 -0400 (EDT) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 526AD4B36D for ; Fri, 4 Sep 2020 05:29:54 -0400 (EDT) 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> Cc: justin.he@arm.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, nd@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu 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. -- 2.17.1 _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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=-13.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT 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 98445C43461 for ; Fri, 4 Sep 2020 09:31:33 +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 5189A205CB for ; Fri, 4 Sep 2020 09:31:33 +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 5189A205CB 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+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=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-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 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 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. -- 2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel