RE: [RFC PATCH v12 10/11] arm64: add mechanism to let user choose which counter to return

[Jianyong Wu]

Hi Marc,

> -----Original Message-----
> From: Marc Zyngier <maz@xxxxxxxxxx>
> Sent: Monday, May 25, 2020 5:17 PM
> To: Richard Cochran <richardcochran@xxxxxxxxx>; Jianyong Wu
> <Jianyong.Wu@xxxxxxx>
> Cc: netdev@xxxxxxxxxxxxxxx; yangbo.lu@xxxxxxx; john.stultz@xxxxxxxxxx;
> tglx@xxxxxxxxxxxxx; pbonzini@xxxxxxxxxx; sean.j.christopherson@xxxxxxxxx;
> Mark Rutland <Mark.Rutland@xxxxxxx>; will@xxxxxxxxxx; Suzuki Poulose
> <Suzuki.Poulose@xxxxxxx>; Steven Price <Steven.Price@xxxxxxx>; linux-
> kernel@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
> kvmarm@xxxxxxxxxxxxxxxxxxxxx; kvm@xxxxxxxxxxxxxxx; Steve Capper
> <Steve.Capper@xxxxxxx>; Kaly Xin <Kaly.Xin@xxxxxxx>; Justin He
> <Justin.He@xxxxxxx>; Wei Chen <Wei.Chen@xxxxxxx>; nd <nd@xxxxxxx>
> 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?

> >
> >> 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.

Good!

Thanks
Jianyong 
 
> 
>          M.
> --
> Jazz is not dead. It just smells funny...