RE: [PATCH v7 05/10] arm64: hyperv: Add interrupt handlers for VMbus and stimer

From: Arnd Bergmann <arnd@arndb.de> Sent: Monday, August 24, 2020 11:54 AM

On Mon, Aug 24, 2020 at 6:46 PM Michael Kelley [off-list ref] wrote:

quoted

Add ARM64-specific code to set up and handle the interrupts
generated by Hyper-V for VMbus messages and for stimer expiration.

This code is architecture dependent and is mostly driven by
architecture independent code in the VMbus driver and the
Hyper-V timer clocksource driver.

This code is built only when CONFIG_HYPERV is enabled.

Signed-off-by: Michael Kelley <redacted>
---
 arch/arm64/hyperv/Makefile        |   2 +-
 arch/arm64/hyperv/mshyperv.c      | 133

++++++++++++++++++++++++++++++++++++++

quoted

 arch/arm64/include/asm/mshyperv.h |  70 ++++++++++++++++++++

I still have the feeling that most of the code in arch/arm64/hyperv/ is
misplaced: the only callers are loadable modules in drivers/hv/, and the
code is not really part of the architecture but part of the platform.

For the arm64 architecture, we have a rule that platform specific
code belongs into device drivers rather than into the architecture
code as we used to do in the linux-2.6 days for arch/arm/.

I don't see hyperv being virtual rather than an SoC as a differentiator
either; it's still just one of many platforms. If you look at
arch/arm64/xen/, you can see that they have managed to get
to a much simpler implementation in comparison.

I'm not sure what the correct solution should be, but what I'd try to
do here is to move every function that just considers the platform
rather than the architecture somewhere into drivers/hv where it
can be linked into the same modules as the existing files when
building for arm64, while trying to keep architecture specific code
in the header file where it can be included from those modules.

OK.  The concept of separating platform from architecture makes
sense to me.  The original separation of the Hyper-V code into
architecture independent portions and x86-specific portions could
use some tweaking now that we're dealing with n=2 architectures.  With
that tweaking, I can reduce the amount of Hyper-V code under arch/x86
and under arch/arm64.

On the flip side, the Hyper-V implementation on x86 and ARM64 has
differences that are semi-related to the architecture.  For example, on
x86 Hyper-V uses synthetic MSRs for a lot of guest-hypervisor setup, while
hypercalls are required on ARM64.  So I'm assuming those differences
will end up in code under arch/x86 and arch/arm64.  Arguably, I could
introduce a level of indirection (such as CONFIG_HYPERV_USE_MSRS vs.
CONFIG_HYPERV_USE_HYPERCALLS) to distinguish the two behaviors.
The selection would be tied to the architecture, and then code in
drivers/hv can #ifdef the two cases.  But I wonder if getting code out of
arch/x86 and arch/arm64 is worth that additional messiness.

Looking at the Xen code in drivers/xen, it looks like a lot of the Xen functionality
is implemented in hypercalls that can be consistent across architectures,
though I was a bit surprised to see a dozen or so instances of #ifdef CONFIG_X86.
Xen also #ifdefs on PV vs. PVHVM, which may handle some architecture
differences implicitly.  But I'm assuming that doing #ifdef <architecture>
in the Hyper-V code in order to reduce code under arch/x86 or arch/arm64
is not the right way to go.

Michael

      Arnd