Jianyong, On Wed, 16 Oct 2019, Jianyong Wu (Arm Technology China) wrote: Please fix your mail client not to copy the full headers into the reply. > > On Wed, 16 Oct 2019, Paolo Bonzini wrote: > > > On 15/10/19 22:13, Thomas Gleixner wrote: > > That's a completely different beast, really. > > > > The clocksource pointer is handed in by the caller and the core code validates > > if the clocksource is the same as the current system clocksource and not the > > other way round. > > > > So there is no need for getting that pointer from the core code because the > > caller knows already which clocksource needs to be active to make.the whole > > cross device timestamp correlation work. And in that case it's the callers > > responsibility to ensure that the pointer is valid which is the case for the > > current use cases. > > > I thinks there is something misunderstanding of my patch. See patch 4/6, > the reason why I add clocksource is that I want to check if the current > clocksouce is arm_arch_counter in virt/kvm/arm/psci.c and nothing to do > with get_device_system_crosststamp. There is no misunderstanding at all. Your patch is broken in several ways as I explained in detail. > So I really need a mechanism to do that check. > > Thanks > Jianyong So just by chance I scrolled further down and found more replies from you. Please trim the reply properly and add your 'Thanks Jianyong' to the end of the mail. > > From your other reply: > > > > > Why add a global id? ARM can add it to archdata similar to how x86 > > > has vclock_mode. But I still think the right thing to do is to > > > include the full system_counterval_t in the result of > > > ktime_get_snapshot. (More in a second, feel free to reply to the other > > email only). > > > > No, the clocksource pointer is not going to be exposed as there is no > > guarantee that it will be still around after the call returns. > > > > It's not even guaranteed to be correct when the store happens in Wu's patch > > simply because the store is done outside of the seqcount protected region. > > Yeah, all of the elements in system_time_snapshot should be captured in > consistency. So I think the consistency will be guaranteed if the store > ops added in the seqcount region. Again. While it is consistent in terms of storage, it's still wrong to expose a pointer to something which has no life time guarantee. Even if your use case is just to compare the pointer it's a bad idea to do that especially without any comment about the pointer validity at all. Thanks, tglx _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
