From: Arnd Bergmann <arnd@xxxxxxxx> Sent: Monday, March 16, 2020 1:30 AM > > On Sat, Mar 14, 2020 at 4:36 PM Michael Kelley <mikelley@xxxxxxxxxxxxx> wrote: > > > > Add ARM64-specific code to initialize the Hyper-V > > hypervisor when booting as a guest VM. Provide functions > > and data structures indicating hypervisor status that > > are needed by VMbus driver. > > > > This code is built only when CONFIG_HYPERV is enabled. > > > > Signed-off-by: Michael Kelley <mikelley@xxxxxxxxxxxxx> > > --- > > arch/arm64/hyperv/hv_core.c | 156 > ++++++++++++++++++++++++++++++++++++++++++++ > > As you are effectively adding a new clocksource driver here, please move the > code to drivers/clocksource and send the patch to the respective maintainers > (added to Cc here), splitting it out from the rest of the patch. > > You should also describe why your platform doesn't just use the normal > architected timer interface. > > > +TIMER_ACPI_DECLARE(hyperv, ACPI_SIG_GTDT, hyperv_init); > > This looks like it registers a driver for the same device as the normal > arch timer. Won't that clash? > > Arnd There is a Hyper-V clocksource driver in drivers/clocksource/hyperv_timer.c. It is architecture independent and works for both x86 and ARM64. The requirement here is really for a place to hang the general Hyper-V initialization code. On the x86 side, there's infrastructure already in place to do hypervisor initialization, but nothing corresponding on the ARM64 side. The TIMER_ACPI_DECLARE hook is admittedly a temporary approach, and I'm happy to hear if someone has a better way to handle this. FWIW, Hyper-V doesn't currently virtualize the ARM arch counter/timer for guest VMs. The Hyper-V synthetic counter/timer in the Hyper-V clocksource driver is used on both ARM64 and x86. But this Hyper-V init code doesn't actually touch the GTDT device, so it won't interfere with the ARM arch counter/timer when a future Hyper-V version does virtualize it. Michael
