Hi Marc, > -----Original Message----- > From: Marc Zyngier <[email protected]> > Sent: Monday, May 25, 2020 5:17 PM > To: Richard Cochran <[email protected]>; Jianyong Wu > <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > Mark Rutland <[email protected]>; [email protected]; Suzuki Poulose > <[email protected]>; Steven Price <[email protected]>; linux- > [email protected]; [email protected]; > [email protected]; [email protected]; Steve Capper > <[email protected]>; Kaly Xin <[email protected]>; Justin He > <[email protected]>; Wei Chen <[email protected]>; nd <[email protected]> > 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...
