[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200524021106.GC335@localhost>
Date: Sat, 23 May 2020 19:11:06 -0700
From: Richard Cochran <richardcochran@...il.com>
To: Jianyong Wu <jianyong.wu@....com>
Cc: netdev@...r.kernel.org, yangbo.lu@....com, john.stultz@...aro.org,
tglx@...utronix.de, pbonzini@...hat.com,
sean.j.christopherson@...el.com, maz@...nel.org,
Mark.Rutland@....com, will@...nel.org, suzuki.poulose@....com,
steven.price@....com, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu,
kvm@...r.kernel.org, Steve.Capper@....com, Kaly.Xin@....com,
justin.he@....com, Wei.Chen@....com, nd@....com
Subject: Re: [RFC PATCH v12 10/11] arm64: add mechanism to let user choose
which counter to return
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.
> 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.
Thanks,
Richard
Powered by blists - more mailing lists