From: Marc Zyngier <maz@kernel.org>
To: Richard Cochran <richardcochran@gmail.com>,
Jianyong Wu <jianyong.wu@arm.com>
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@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
Subject: Re: [RFC PATCH v12 10/11] arm64: add mechanism to let user choose which counter to return
Date: Mon, 25 May 2020 10:17:18 +0100 [thread overview]
Message-ID: <306951e4945b9e486dc98818ba24466d@kernel.org> (raw)
In-Reply-To: <20200524021106.GC335@localhost>
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.
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.
>
>> diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
>> index fef72f29f3c8..8b0a7b328bcd 100644
>> --- a/drivers/ptp/ptp_chardev.c
>> +++ b/drivers/ptp/ptp_chardev.c
>> @@ -123,6 +123,9 @@ long ptp_ioctl(struct posix_clock *pc, unsigned
>> int cmd, unsigned long arg)
>> struct timespec64 ts;
>> int enable, err = 0;
>>
>> +#ifdef CONFIG_ARM64
>> + static long flag;
>
> static? This is not going to fly.
>
>> + * In most cases, we just need virtual counter from host and
>> + * there is limited scenario using this to get physical counter
>> + * in guest.
>> + * Be careful to use this as there is no way to set it back
>> + * unless you reinstall the module.
>
> How on earth is the user supposed to know this?
>
> From your description, this "flag" really should be a module
> parameter.
Not even that. If anything, the driver can obtain full knowledge of
which
counter is in use without any help. And the hard truth is that it is
*always* the virtual counter as far as Linux is concerned.
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Richard Cochran <richardcochran@gmail.com>,
Jianyong Wu <jianyong.wu@arm.com>
Cc: justin.he@arm.com, Wei.Chen@arm.com, kvm@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
sean.j.christopherson@intel.com, steven.price@arm.com,
john.stultz@linaro.org, yangbo.lu@nxp.com, pbonzini@redhat.com,
tglx@linutronix.de, nd@arm.com, will@kernel.org,
kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v12 10/11] arm64: add mechanism to let user choose which counter to return
Date: Mon, 25 May 2020 10:17:18 +0100 [thread overview]
Message-ID: <306951e4945b9e486dc98818ba24466d@kernel.org> (raw)
In-Reply-To: <20200524021106.GC335@localhost>
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.
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.
>
>> diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
>> index fef72f29f3c8..8b0a7b328bcd 100644
>> --- a/drivers/ptp/ptp_chardev.c
>> +++ b/drivers/ptp/ptp_chardev.c
>> @@ -123,6 +123,9 @@ long ptp_ioctl(struct posix_clock *pc, unsigned
>> int cmd, unsigned long arg)
>> struct timespec64 ts;
>> int enable, err = 0;
>>
>> +#ifdef CONFIG_ARM64
>> + static long flag;
>
> static? This is not going to fly.
>
>> + * In most cases, we just need virtual counter from host and
>> + * there is limited scenario using this to get physical counter
>> + * in guest.
>> + * Be careful to use this as there is no way to set it back
>> + * unless you reinstall the module.
>
> How on earth is the user supposed to know this?
>
> From your description, this "flag" really should be a module
> parameter.
Not even that. If anything, the driver can obtain full knowledge of
which
counter is in use without any help. And the hard truth is that it is
*always* the virtual counter as far as Linux is concerned.
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
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Richard Cochran <richardcochran@gmail.com>,
Jianyong Wu <jianyong.wu@arm.com>
Cc: Mark.Rutland@arm.com, justin.he@arm.com, Wei.Chen@arm.com,
kvm@vger.kernel.org, suzuki.poulose@arm.com,
netdev@vger.kernel.org, Steve.Capper@arm.com,
linux-kernel@vger.kernel.org, sean.j.christopherson@intel.com,
steven.price@arm.com, Kaly.Xin@arm.com, john.stultz@linaro.org,
yangbo.lu@nxp.com, pbonzini@redhat.com, tglx@linutronix.de,
nd@arm.com, will@kernel.org, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v12 10/11] arm64: add mechanism to let user choose which counter to return
Date: Mon, 25 May 2020 10:17:18 +0100 [thread overview]
Message-ID: <306951e4945b9e486dc98818ba24466d@kernel.org> (raw)
In-Reply-To: <20200524021106.GC335@localhost>
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.
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.
>
>> diff --git a/drivers/ptp/ptp_chardev.c b/drivers/ptp/ptp_chardev.c
>> index fef72f29f3c8..8b0a7b328bcd 100644
>> --- a/drivers/ptp/ptp_chardev.c
>> +++ b/drivers/ptp/ptp_chardev.c
>> @@ -123,6 +123,9 @@ long ptp_ioctl(struct posix_clock *pc, unsigned
>> int cmd, unsigned long arg)
>> struct timespec64 ts;
>> int enable, err = 0;
>>
>> +#ifdef CONFIG_ARM64
>> + static long flag;
>
> static? This is not going to fly.
>
>> + * In most cases, we just need virtual counter from host and
>> + * there is limited scenario using this to get physical counter
>> + * in guest.
>> + * Be careful to use this as there is no way to set it back
>> + * unless you reinstall the module.
>
> How on earth is the user supposed to know this?
>
> From your description, this "flag" really should be a module
> parameter.
Not even that. If anything, the driver can obtain full knowledge of
which
counter is in use without any help. And the hard truth is that it is
*always* the virtual counter as far as Linux is concerned.
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
next prev parent reply other threads:[~2020-05-25 9:17 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-22 8:37 [RFC PATCH v12 0/11] Enable ptp_kvm for arm64 Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` [RFC PATCH v12 01/11] arm64: Probe for the presence of KVM hypervisor services during boot Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` [RFC PATCH v12 02/11] arm/arm64: KVM: Advertise KVM UID to guests via SMCCC Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` [RFC PATCH v12 03/11] psci: export smccc conduit get helper Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 13:12 ` Sudeep Holla
2020-05-22 13:12 ` Sudeep Holla
2020-05-22 13:12 ` Sudeep Holla
2020-05-25 1:37 ` Jianyong Wu
2020-05-25 1:37 ` Jianyong Wu
2020-05-25 1:37 ` Jianyong Wu
2020-05-26 10:10 ` Sudeep Holla
2020-05-26 10:10 ` Sudeep Holla
2020-05-26 10:10 ` Sudeep Holla
2020-05-27 1:18 ` Jianyong Wu
2020-05-27 1:18 ` Jianyong Wu
2020-05-27 1:18 ` Jianyong Wu
2020-05-22 8:37 ` [RFC PATCH v12 04/11] ptp: Reorganize ptp_kvm modules to make it arch-independent Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` [RFC PATCH v12 05/11] time: Add mechanism to recognize clocksource in time_get_snapshot Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-23 3:35 ` kbuild test robot
2020-05-28 16:36 ` Thomas Gleixner
2020-05-28 16:36 ` Thomas Gleixner
2020-05-28 16:36 ` Thomas Gleixner
2020-05-29 1:05 ` Jianyong Wu
2020-05-29 1:05 ` Jianyong Wu
2020-05-29 1:05 ` Jianyong Wu
2020-05-22 8:37 ` [RFC PATCH v12 06/11] clocksource: Add clocksource id for arm arch counter Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` [RFC PATCH v12 07/11] psci: Add hypercall service for kvm ptp Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 14:18 ` Steven Price
2020-05-22 14:18 ` Steven Price
2020-05-22 14:18 ` Steven Price
2020-05-25 2:11 ` Jianyong Wu
2020-05-25 2:11 ` Jianyong Wu
2020-05-25 2:11 ` Jianyong Wu
2020-05-26 11:02 ` Steven Price
2020-05-26 11:02 ` Steven Price
2020-05-26 11:02 ` Steven Price
2020-05-27 6:06 ` Jianyong Wu
2020-05-27 6:06 ` Jianyong Wu
2020-05-27 6:06 ` Jianyong Wu
2020-05-22 8:37 ` [RFC PATCH v12 08/11] ptp: arm64: Enable ptp_kvm for arm/arm64 Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-26 14:24 ` kbuild test robot
2020-05-22 8:37 ` [RFC PATCH v12 09/11] ptp: extend input argument for getcrosstimestamp API Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-24 1:42 ` Richard Cochran
2020-05-24 1:42 ` Richard Cochran
2020-05-24 1:42 ` Richard Cochran
2020-05-22 8:37 ` [RFC PATCH v12 10/11] arm64: add mechanism to let user choose which counter to return Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-24 1:47 ` Richard Cochran
2020-05-24 1:47 ` Richard Cochran
2020-05-24 1:47 ` Richard Cochran
2020-05-24 2:11 ` Richard Cochran
2020-05-24 2:11 ` Richard Cochran
2020-05-24 2:11 ` Richard Cochran
2020-05-25 4:50 ` Jianyong Wu
2020-05-25 4:50 ` Jianyong Wu
2020-05-25 4:50 ` Jianyong Wu
2020-05-25 6:16 ` Richard Cochran
2020-05-25 6:16 ` Richard Cochran
2020-05-25 6:16 ` Richard Cochran
2020-05-25 6:29 ` Jianyong Wu
2020-05-25 6:29 ` Jianyong Wu
2020-05-25 6:29 ` Jianyong Wu
2020-05-25 9:17 ` Marc Zyngier [this message]
2020-05-25 9:17 ` Marc Zyngier
2020-05-25 9:17 ` Marc Zyngier
2020-05-25 14:18 ` Jianyong Wu
2020-05-25 14:18 ` Jianyong Wu
2020-05-25 14:18 ` Jianyong Wu
2020-05-25 15:28 ` Marc Zyngier
2020-05-25 15:28 ` Marc Zyngier
2020-05-25 15:28 ` Marc Zyngier
2020-05-22 8:37 ` [RFC PATCH v12 11/11] arm64: Add kvm capability check extension for ptp_kvm Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
2020-05-22 8:37 ` Jianyong Wu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=306951e4945b9e486dc98818ba24466d@kernel.org \
--to=maz@kernel.org \
--cc=Kaly.Xin@arm.com \
--cc=Mark.Rutland@arm.com \
--cc=Steve.Capper@arm.com \
--cc=Wei.Chen@arm.com \
--cc=jianyong.wu@arm.com \
--cc=john.stultz@linaro.org \
--cc=justin.he@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nd@arm.com \
--cc=netdev@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=richardcochran@gmail.com \
--cc=sean.j.christopherson@intel.com \
--cc=steven.price@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=tglx@linutronix.de \
--cc=will@kernel.org \
--cc=yangbo.lu@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.