Messages in this thread | | | Date | Tue, 28 Jan 2020 11:48:32 +0000 | From | Marc Zyngier <> | Subject | Re: [RFC 0/6] vDSO support for Hyper-V guest on ARM64 |
| |
On 2020-01-28 05:58, Boqun Feng wrote: > On Fri, Jan 24, 2020 at 10:24:44AM +0000, Vincenzo Frascino wrote: >> Hi Boqun Feng, >> >> On 24/01/2020 06:32, Boqun Feng wrote: >> > Hi Vincenzo, >> > >> >> [...] >> >> >> >> >> I had a look to your patches and overall, I could not understand why we can't >> >> use the arch_timer to do the same things you are doing with the one you >> >> introduced in this series. What confuses me is that KVM works just fine with the >> >> arch_timer which was designed with virtualization in mind. Why do we need >> >> another one? Could you please explain? >> >> >> > >> > Please note that the guest VM on Hyper-V for ARM64 doesn't use >> > arch_timer as the clocksource. See: >> > >> > https://lore.kernel.org/linux-arm-kernel/1570129355-16005-7-git-send-email-mikelley@microsoft.com/ >> > >> > , ACPI_SIG_GTDT is used for setting up Hyper-V synthetic clocksource >> > and other initialization work. >> > >> >> I had a look a look at it and my question stands, why do we need >> another timer >> on arm64? >> > > Sorry for the late response. It's weekend and Chinese New Year, so I > got > to spend some time making (and mostly eating) dumplings ;-)
And you haven't been sharing! ;-)
> After discussion with Michael, here is some explanation why we need > another timer: > > The synthetic clocks that Hyper-V presents in a guest VM were > originally > created for the x86 architecture. They provide a level of abstraction > that solves problems like continuity across live migrations where the > hardware clock (i.e., TSC in the case x86) frequency may be different > across the migration. When Hyper-V was brought to ARM64, this > abstraction was maintained to provide consistency across the x86 and > ARM64 architectures, and for both Windows and Linux guest VMs. The > core Linux code for the Hyper-V clocks (in > drivers/clocksource/hyperv_timer.c) is architecture neutral and works > on > both x86 and ARM64. As you can see, this part is done in Michael's > patchset. > > Arguably, Hyper-V for ARM64 should have optimized for consistency with > the ARM64 community rather with the existing x86 implementation and > existing guest code in Windows. But at this point, it is what it is, > and the Hyper-V clocks do solve problems like migration that aren’t > addressed in ARM64 until v8.4 of the architecture with the addition of > the counter hardware scaling feature. Hyper-V doesn’t currently map the > ARM arch timer interrupts into guest VMs, so we need to use the > existing > Hyper-V clocks and the common code that already exists.
The migration thing is a bit of a red herring. Do you really anticipate VM migration across systems that have their timers running at different frequencies *today*? And even if you did, there are ways to deal with it with the arch timers (patches to that effect were posted on the list, and there was even a bit of an ARM spec for it).
I find it odd to try and make arm64 "just another x86", while the architecture gives you most of what you need already. I guess I'm tainted.
Thanks,
M. -- Who you jivin' with that Cosmik Debris?
| |