netdev - RE: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <HE1PR0801MB1676A0D2B90A52997DD15675F4850@HE1PR0801MB1676.eurprd08.prod.outlook.com>
Date:   Mon, 23 Sep 2019 03:19:06 +0000
From:   "Jianyong Wu (Arm Technology China)" <Jianyong.Wu@....com>
To:     Paolo Bonzini <pbonzini@...hat.com>, Marc Zyngier <maz@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "yangbo.lu@....com" <yangbo.lu@....com>,
        "john.stultz@...aro.org" <john.stultz@...aro.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "sean.j.christopherson@...el.com" <sean.j.christopherson@...el.com>,
        "richardcochran@...il.com" <richardcochran@...il.com>,
        Mark Rutland <Mark.Rutland@....com>,
        Will Deacon <Will.Deacon@....com>,
        Suzuki Poulose <Suzuki.Poulose@....com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        Steve Capper <Steve.Capper@....com>,
        "Kaly Xin (Arm Technology China)" <Kaly.Xin@....com>,
        "Justin He (Arm Technology China)" <Justin.He@....com>,
        nd <nd@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.

Hi Marc, Paolo,

> -----Original Message-----
> From: Paolo Bonzini <pbonzini@...hat.com>
> Sent: Thursday, September 19, 2019 8:13 PM
> To: Marc Zyngier <maz@...nel.org>; Jianyong Wu (Arm Technology China)
> <Jianyong.Wu@....com>; netdev@...r.kernel.org; yangbo.lu@....com;
> john.stultz@...aro.org; tglx@...utronix.de; sean.j.christopherson@...el.com;
> richardcochran@...il.com; Mark Rutland <Mark.Rutland@....com>; Will
> Deacon <Will.Deacon@....com>; Suzuki Poulose
> <Suzuki.Poulose@....com>
> Cc: linux-kernel@...r.kernel.org; kvm@...r.kernel.org; Steve Capper
> <Steve.Capper@....com>; Kaly Xin (Arm Technology China)
> <Kaly.Xin@....com>; Justin He (Arm Technology China)
> <Justin.He@....com>; nd <nd@....com>; linux-arm-
> kernel@...ts.infradead.org
> Subject: Re: [RFC PATCH v3 4/6] psci: Add hvc call service for ptp_kvm.
> 
> On 19/09/19 13:39, Marc Zyngier wrote:
> >> I don't think it's ugly but more important, using tk->tkr_mono.clock
> >> is incorrect.  See how the x86 code hardcodes &kvm_clock, it's the
> >> same for ARM.
> > Not really. The guest kernel is free to use any clocksource it wishes.
> 
> Understood, in fact it's the same on x86.
> 
> However, for PTP to work, the cycles value returned by the clocksource must
> match the one returned by the hypercall.  So for ARM
> get_device_system_crosststamp must receive the arch timer clocksource, so
> that it will return -ENODEV if the active clocksource is anything else.
> 

After day's reflection on this, I'm a little clear about this issue, let me clarify it.
I think there is three principles for this issue:
(1): guest and host can use different clocksouces as their current clocksouce at the same time
and we can't  or it's not easy to probe that if they use the same one.
(2): the cycle value and the clocksouce which passed to get_device_system_crosststamp must be match.
(3): ptp_kvm target to increase the time sync precision so we should choose a high rate clocksource as ptp_kvm clocksource.
Base on (1) and (2) we can deduce that the ptp_kvm clocksource should be better a fixed one. So we can test if the cycle and
clocksource is match. 
Base on (3) the arch_sys_timer should be chosen, as it's the best clocksource by far for arm.

Thanks
Jianyong Wu

> Paolo
> 
> > In some cases, it is actually desirable (like these broken systems
> > that cannot use an in-kernel irqchip...). Maybe it is that on x86 the
> > guest only uses the kvm_clock, but that's a much harder sell on ARM.
> > The fact that ptp_kvm assumes that the clocksource is fixed doesn't
> > seem correct in that case.