Messages in this thread | | | From | Arnd Bergmann <> | Date | Wed, 26 Aug 2020 09:18:53 +0200 | Subject | Re: [PATCH v7 07/10] arm64: hyperv: Initialize hypervisor on boot |
| |
On Tue, Aug 25, 2020 at 11:20 PM Michael Kelley <mikelley@microsoft.com> wrote: > From: Arnd Bergmann <arnd@arndb.de> Sent: Monday, August 24, 2020 11:34 AM > > On Mon, Aug 24, 2020 at 6:48 PM Michael Kelley <mikelley@microsoft.com> wrote: > > > > I think this has come up before, and I still don't consider it an acceptable > > hack to hook platform initialization code into the timer code. > > > > Please split out the timer into a standalone driver in drivers/clocksource > > that can get reviewed by the clocksource maintainers. > > I see two related topics here.
Agreed
> First, the Hyper-V clocksource driver is > drivers/clocksource/hyperv_timer.c. The code is architecture independent > and is used today on the x86 side and for ARM64 in this patch series. A few > architecture specific calls are satisfied by code under arch/x86, and in this > patch series, under arch/arm64. Is there some aspect of this driver that > needs reconsideration? I just want to make sure to understand what you > are getting at.
For the clocksource driver, I would like to see the arm64 specific bits (the code you add in arch/arm64 that are only relevant to this driver) moved out of arch/arm64 and into drivers/clocksource, in whatever form the clocksource maintainers prefer. I would suggest having a separate file that can get linked along with the architecture-independent part of that driver.
> Second is the question of where/how to do Hyper-V specific initialization. > I agree that hanging it off the timer initialization isn't a great approach. > Should I add a Hyper-V specific initialization call at the appropriate point > in the ARM64 init sequence? The x86 side has some structure for handling > multiple hypervisors, and the Hyper-V initialization code naturally plugs into > that structure. I'm certainly open to suggestions on the best way to handle > it for ARM64.
Yes, that is where I was getting at. Maybe the x86 abstraction for handling multiple hypervisors can be lifted out of arch/x86/ into common code?
Arnd
| |