From: Thomas Gleixner <tglx@xxxxxxxxxxxxx> Sent: Sunday, June 23, 2019 3:13 PM > > I have no objections if you collect hyper-v stuff, quite the contrary, but > changes which touch other subsystems need to be coordinated upfront. That's > all I'm asking for. > > Btw, that clocksource stuff looks good code wise, just the change logs need > some care and after the VDSO stuff hits next we need to sort out the > logistics. I hope these changes are completely self contained. If not we'll > find a solution. > In my view, the only thing that potentially needs a solution is where the Hyper-V clock code used by VDSO ends up in the code tree. I think the right long term place is include/clocksource/hyperv_timer.h. That location is architecture neutral, and the same Hyper-V clock code will be shared by the Hyper-V on ARM64 support that's in process. Vincenzo's patch set creates a new file arch/x86/include/asm/mshyperv-tsc.h, which I will want to move when creating the separate Hyper-V clocksource driver. If you're OK with that file existing for a release and then going away, that's fine. Alternatively, put the code in include/clocksource/hyperv_timer.h now as part of the VDSO patch set so it's in the right place from the start. My subsequent patch set will add a few additional tweaks to remove x86-isms and fully integrate with the separate Hyper-V clocksource driver. Michael
