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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 0EC2DC433E0 for ; Mon, 25 May 2020 15:28:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D61BD207CB for ; Mon, 25 May 2020 15:28:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590420505; bh=3X4sQ7kcpAcBdWmFPLh2z6FUnu+whu05DPLM1j+9VQY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=wFXK7bzaSOqZgmBA5uufptHRSuZgvzBZ08/A7PlF7sLLulYeP/rTCUUsbPrg57j0b fEDfV1bm3cA7kpSQuKL88b6IZd1om73Rnm2qqQhodV/uTmRfcyahiCWQZNsrkGL+b6 ZoqP1fWdYIRC0voGX3iocWxOy0/1QKURsbT4w1Ck= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404167AbgEYP2Z (ORCPT ); Mon, 25 May 2020 11:28:25 -0400 Received: from mail.kernel.org ([198.145.29.99]:51378 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2403999AbgEYP2Y (ORCPT ); Mon, 25 May 2020 11:28:24 -0400 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 B44D92071A; Mon, 25 May 2020 15:28:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590420503; bh=3X4sQ7kcpAcBdWmFPLh2z6FUnu+whu05DPLM1j+9VQY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=0bBuzBY5wC1xcpMo04SVEVYyNO8F3N5GWqP7oDFDTbPCo3EUisqzVks3B99I4/hdY /iEgGaONpIC9cmuYkN8WpvOyZ6fzMILw87y7sn4R0VuCPQebUSBI+bsP0/+gZVHcVq /FsxUauOXD8YIvXLhbH0AjW3jJDp8Sul7gdt/vF0= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jdF1Z-00FC3W-Mv; Mon, 25 May 2020 16:28:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 25 May 2020 16:28:21 +0100 From: Marc Zyngier To: Jianyong Wu Cc: Richard Cochran , netdev@vger.kernel.org, yangbo.lu@nxp.com, john.stultz@linaro.org, tglx@linutronix.de, pbonzini@redhat.com, sean.j.christopherson@intel.com, Mark Rutland , will@kernel.org, Suzuki Poulose , Steven Price , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Steve Capper , Kaly Xin , Justin He , Wei Chen , nd Subject: Re: [RFC PATCH v12 10/11] arm64: add mechanism to let user choose which counter to return In-Reply-To: References: <20200522083724.38182-1-jianyong.wu@arm.com> <20200522083724.38182-11-jianyong.wu@arm.com> <20200524021106.GC335@localhost> <306951e4945b9e486dc98818ba24466d@kernel.org> User-Agent: Roundcube Webmail/1.4.4 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: Jianyong.Wu@arm.com, richardcochran@gmail.com, netdev@vger.kernel.org, yangbo.lu@nxp.com, john.stultz@linaro.org, tglx@linutronix.de, pbonzini@redhat.com, sean.j.christopherson@intel.com, Mark.Rutland@arm.com, will@kernel.org, Suzuki.Poulose@arm.com, Steven.Price@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Steve.Capper@arm.com, Kaly.Xin@arm.com, Justin.He@arm.com, Wei.Chen@arm.com, nd@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-05-25 15:18, Jianyong Wu wrote: > Hi Marc, > >> -----Original Message----- >> From: Marc Zyngier >> Sent: Monday, May 25, 2020 5:17 PM >> To: Richard Cochran ; Jianyong Wu >> >> Cc: netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org; >> tglx@linutronix.de; pbonzini@redhat.com; >> sean.j.christopherson@intel.com; >> Mark Rutland ; will@kernel.org; Suzuki Poulose >> ; Steven Price ; linux- >> kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; >> kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org; Steve Capper >> ; Kaly Xin ; Justin He >> ; Wei Chen ; nd >> Subject: Re: [RFC PATCH v12 10/11] arm64: add mechanism to let user >> choose which counter to return >> >> On 2020-05-24 03:11, Richard Cochran wrote: >> > On Fri, May 22, 2020 at 04:37:23PM +0800, Jianyong Wu wrote: >> >> In general, vm inside will use virtual counter compered with host use >> >> phyical counter. But in some special scenarios, like nested >> >> virtualization, phyical counter maybe used by vm. A interface added >> >> in ptp_kvm driver to offer a mechanism to let user choose which >> >> counter should be return from host. >> > >> > Sounds like you have two time sources, one for normal guest, and one >> > for nested. Why not simply offer the correct one to user space >> > automatically? If that cannot be done, then just offer two PHC >> > devices with descriptive names. >> >> There is no such thing as a distinction between nested or non-nested. >> Both counters are available to the guest at all times, and said guest >> can >> choose whichever it wants to use. So the hypervisor (KVM) has to >> support >> both counters as a reference. >> > It's great that we can decide which counter to return in guest kernel. > So we can abandon these code, including patch 9/11 and 10/11, that > expose the interface to userspace to do the decision. > >> For a Linux guest, we always know which reference we're using (the >> virtual >> counter). So it is pointless to expose the choice to userspace at all. >> > So, we should throw these code of deciding counter type in linux > driver away and just keep the hypercall service of providing both > virtual counter and physical counter in linux to server non-linux > guest. > Am I right? Exactly. We control Linux, and so far nothing is using the physical counter directly. It is only using the virtual counter. On the other side, this is *only* Linux. Other operating systems will need to pick the reference clock that matches their own. If one day we change Linux to use the physical counter, we'll have to do the same thing. M. -- Jazz is not dead. It just smells funny... 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=-0.8 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 B3037C433DF for ; Mon, 25 May 2020 15:28:31 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 359192071C for ; Mon, 25 May 2020 15:28:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="0bBuzBY5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 359192071C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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 A3ECF4B24F; Mon, 25 May 2020 11:28:30 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@kernel.org 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 qs1I28F6Uxke; Mon, 25 May 2020 11:28:28 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 3D9D34B201; Mon, 25 May 2020 11:28:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 3B02D4B1EB for ; Mon, 25 May 2020 11:28:27 -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 J+XRQdN2zoRa for ; Mon, 25 May 2020 11:28:25 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 19C514B1E8 for ; Mon, 25 May 2020 11:28:25 -0400 (EDT) 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 B44D92071A; Mon, 25 May 2020 15:28:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590420503; bh=3X4sQ7kcpAcBdWmFPLh2z6FUnu+whu05DPLM1j+9VQY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=0bBuzBY5wC1xcpMo04SVEVYyNO8F3N5GWqP7oDFDTbPCo3EUisqzVks3B99I4/hdY /iEgGaONpIC9cmuYkN8WpvOyZ6fzMILw87y7sn4R0VuCPQebUSBI+bsP0/+gZVHcVq /FsxUauOXD8YIvXLhbH0AjW3jJDp8Sul7gdt/vF0= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jdF1Z-00FC3W-Mv; Mon, 25 May 2020 16:28:21 +0100 MIME-Version: 1.0 Date: Mon, 25 May 2020 16:28:21 +0100 From: Marc Zyngier To: Jianyong Wu Subject: Re: [RFC PATCH v12 10/11] arm64: add mechanism to let user choose which counter to return In-Reply-To: References: <20200522083724.38182-1-jianyong.wu@arm.com> <20200522083724.38182-11-jianyong.wu@arm.com> <20200524021106.GC335@localhost> <306951e4945b9e486dc98818ba24466d@kernel.org> User-Agent: Roundcube Webmail/1.4.4 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: Jianyong.Wu@arm.com, richardcochran@gmail.com, netdev@vger.kernel.org, yangbo.lu@nxp.com, john.stultz@linaro.org, tglx@linutronix.de, pbonzini@redhat.com, sean.j.christopherson@intel.com, Mark.Rutland@arm.com, will@kernel.org, Suzuki.Poulose@arm.com, Steven.Price@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Steve.Capper@arm.com, Kaly.Xin@arm.com, Justin.He@arm.com, Wei.Chen@arm.com, nd@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: Justin He , Wei Chen , kvm@vger.kernel.org, netdev@vger.kernel.org, Richard Cochran , linux-kernel@vger.kernel.org, sean.j.christopherson@intel.com, Steven Price , 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 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On 2020-05-25 15:18, Jianyong Wu wrote: > Hi Marc, > >> -----Original Message----- >> From: Marc Zyngier >> Sent: Monday, May 25, 2020 5:17 PM >> To: Richard Cochran ; Jianyong Wu >> >> Cc: netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org; >> tglx@linutronix.de; pbonzini@redhat.com; >> sean.j.christopherson@intel.com; >> Mark Rutland ; will@kernel.org; Suzuki Poulose >> ; Steven Price ; linux- >> kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; >> kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org; Steve Capper >> ; Kaly Xin ; Justin He >> ; Wei Chen ; nd >> Subject: Re: [RFC PATCH v12 10/11] arm64: add mechanism to let user >> choose which counter to return >> >> On 2020-05-24 03:11, Richard Cochran wrote: >> > On Fri, May 22, 2020 at 04:37:23PM +0800, Jianyong Wu wrote: >> >> In general, vm inside will use virtual counter compered with host use >> >> phyical counter. But in some special scenarios, like nested >> >> virtualization, phyical counter maybe used by vm. A interface added >> >> in ptp_kvm driver to offer a mechanism to let user choose which >> >> counter should be return from host. >> > >> > Sounds like you have two time sources, one for normal guest, and one >> > for nested. Why not simply offer the correct one to user space >> > automatically? If that cannot be done, then just offer two PHC >> > devices with descriptive names. >> >> There is no such thing as a distinction between nested or non-nested. >> Both counters are available to the guest at all times, and said guest >> can >> choose whichever it wants to use. So the hypervisor (KVM) has to >> support >> both counters as a reference. >> > It's great that we can decide which counter to return in guest kernel. > So we can abandon these code, including patch 9/11 and 10/11, that > expose the interface to userspace to do the decision. > >> For a Linux guest, we always know which reference we're using (the >> virtual >> counter). So it is pointless to expose the choice to userspace at all. >> > So, we should throw these code of deciding counter type in linux > driver away and just keep the hypercall service of providing both > virtual counter and physical counter in linux to server non-linux > guest. > Am I right? Exactly. We control Linux, and so far nothing is using the physical counter directly. It is only using the virtual counter. On the other side, this is *only* Linux. Other operating systems will need to pick the reference clock that matches their own. If one day we change Linux to use the physical counter, we'll have to do the same thing. M. -- Jazz is not dead. It just smells funny... _______________________________________________ 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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 F1394C433E0 for ; Mon, 25 May 2020 15:28:29 +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 C0A0E2071C for ; Mon, 25 May 2020 15:28:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="pZcmvxT5"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="0bBuzBY5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C0A0E2071C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=MUrolDBvMxL467hk53WFYwa+i7DiZoguJhtEcTYEibk=; b=pZcmvxT5HtzTsa2qi9d43vV9N mzqpS3cyUQX4hQ/BkPvFyxyLqYdAT3ZpvxjcIN9UiIAsSkrx37KpAa1E78tLIMlCM0Xf5hmcgEJn2 Pt6Bk+K9Ddx2tFkhdIwUQh4wec97htvwI5avbPMjnahVNzBjYIT571UR223BmxO3h9Hn4rY6g3WrP b7T4xqXOz8hkTZyNFabp8LT5uu2vED7kn210JUJC3ojZlSrcoAUHuLtPX5eEx9J8SvFyY4NyXlUoc kW82BvLIoRdJAy9nIGz/nULlzD8DLUjkBu9JepzyfIjKWTYrBh/SjTQUQMBtQp+bSnQ2ynnT3swFt 5hOMmvSiA==; 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 1jdF1h-0006A2-1p; Mon, 25 May 2020 15:28:29 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jdF1e-00068z-7a for linux-arm-kernel@lists.infradead.org; Mon, 25 May 2020 15:28:27 +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 B44D92071A; Mon, 25 May 2020 15:28:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1590420503; bh=3X4sQ7kcpAcBdWmFPLh2z6FUnu+whu05DPLM1j+9VQY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=0bBuzBY5wC1xcpMo04SVEVYyNO8F3N5GWqP7oDFDTbPCo3EUisqzVks3B99I4/hdY /iEgGaONpIC9cmuYkN8WpvOyZ6fzMILw87y7sn4R0VuCPQebUSBI+bsP0/+gZVHcVq /FsxUauOXD8YIvXLhbH0AjW3jJDp8Sul7gdt/vF0= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jdF1Z-00FC3W-Mv; Mon, 25 May 2020 16:28:21 +0100 MIME-Version: 1.0 Date: Mon, 25 May 2020 16:28:21 +0100 From: Marc Zyngier To: Jianyong Wu Subject: Re: [RFC PATCH v12 10/11] arm64: add mechanism to let user choose which counter to return In-Reply-To: References: <20200522083724.38182-1-jianyong.wu@arm.com> <20200522083724.38182-11-jianyong.wu@arm.com> <20200524021106.GC335@localhost> <306951e4945b9e486dc98818ba24466d@kernel.org> User-Agent: Roundcube Webmail/1.4.4 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: Jianyong.Wu@arm.com, richardcochran@gmail.com, netdev@vger.kernel.org, yangbo.lu@nxp.com, john.stultz@linaro.org, tglx@linutronix.de, pbonzini@redhat.com, sean.j.christopherson@intel.com, Mark.Rutland@arm.com, will@kernel.org, Suzuki.Poulose@arm.com, Steven.Price@arm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, Steve.Capper@arm.com, Kaly.Xin@arm.com, Justin.He@arm.com, Wei.Chen@arm.com, nd@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-20200525_082826_314145_BD6C1DD5 X-CRM114-Status: GOOD ( 17.06 ) 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: Mark Rutland , Justin He , Wei Chen , kvm@vger.kernel.org, Suzuki Poulose , netdev@vger.kernel.org, Richard Cochran , 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-05-25 15:18, Jianyong Wu wrote: > Hi Marc, > >> -----Original Message----- >> From: Marc Zyngier >> Sent: Monday, May 25, 2020 5:17 PM >> To: Richard Cochran ; Jianyong Wu >> >> Cc: netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org; >> tglx@linutronix.de; pbonzini@redhat.com; >> sean.j.christopherson@intel.com; >> Mark Rutland ; will@kernel.org; Suzuki Poulose >> ; Steven Price ; linux- >> kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; >> kvmarm@lists.cs.columbia.edu; kvm@vger.kernel.org; Steve Capper >> ; Kaly Xin ; Justin He >> ; Wei Chen ; nd >> Subject: Re: [RFC PATCH v12 10/11] arm64: add mechanism to let user >> choose which counter to return >> >> On 2020-05-24 03:11, Richard Cochran wrote: >> > On Fri, May 22, 2020 at 04:37:23PM +0800, Jianyong Wu wrote: >> >> In general, vm inside will use virtual counter compered with host use >> >> phyical counter. But in some special scenarios, like nested >> >> virtualization, phyical counter maybe used by vm. A interface added >> >> in ptp_kvm driver to offer a mechanism to let user choose which >> >> counter should be return from host. >> > >> > Sounds like you have two time sources, one for normal guest, and one >> > for nested. Why not simply offer the correct one to user space >> > automatically? If that cannot be done, then just offer two PHC >> > devices with descriptive names. >> >> There is no such thing as a distinction between nested or non-nested. >> Both counters are available to the guest at all times, and said guest >> can >> choose whichever it wants to use. So the hypervisor (KVM) has to >> support >> both counters as a reference. >> > It's great that we can decide which counter to return in guest kernel. > So we can abandon these code, including patch 9/11 and 10/11, that > expose the interface to userspace to do the decision. > >> For a Linux guest, we always know which reference we're using (the >> virtual >> counter). So it is pointless to expose the choice to userspace at all. >> > So, we should throw these code of deciding counter type in linux > driver away and just keep the hypercall service of providing both > virtual counter and physical counter in linux to server non-linux > guest. > Am I right? Exactly. We control Linux, and so far nothing is using the physical counter directly. It is only using the virtual counter. On the other side, this is *only* Linux. Other operating systems will need to pick the reference clock that matches their own. If one day we change Linux to use the physical counter, we'll have to do the same thing. M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel