Re: [Xen-devel] [RFC 0/6] vDSO support for Hyper-V guest on ARM64

[Marc Zyngier <maz@xxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx/
> > >
> > > ,  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?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel