Message-ID:
 <SN6PR02MB41573F55DBAAF124CFD92840D4332@SN6PR02MB4157.namprd02.prod.outlook.com>
Date: Sun, 8 Dec 2024 02:59:54 +0000
From: Michael Kelley <mhklinux@...look.com>
To: Nuno Das Neves <nunodasneves@...ux.microsoft.com>,
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-arch@...r.kernel.org"
	<linux-arch@...r.kernel.org>
CC: "kys@...rosoft.com" <kys@...rosoft.com>, "haiyangz@...rosoft.com"
	<haiyangz@...rosoft.com>, "wei.liu@...nel.org" <wei.liu@...nel.org>,
	"decui@...rosoft.com" <decui@...rosoft.com>, "catalin.marinas@....com"
	<catalin.marinas@....com>, "will@...nel.org" <will@...nel.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com"
	<mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "x86@...nel.org"
	<x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>, "arnd@...db.de"
	<arnd@...db.de>, "jinankjain@...ux.microsoft.com"
	<jinankjain@...ux.microsoft.com>, "muminulrussell@...il.com"
	<muminulrussell@...il.com>, "skinsburskii@...ux.microsoft.com"
	<skinsburskii@...ux.microsoft.com>, "mukeshrathor@...rosoft.com"
	<mukeshrathor@...rosoft.com>
Subject: RE: [PATCH 0/2] hyperv: Move some features to common code

From: Nuno Das Neves <nunodasneves@...ux.microsoft.com> Sent: Friday, December 6, 2024 2:22 PM
> 
> There are several bits of Hyper-V-related code that today live in
> arch/x86 but are not really specific to x86_64 and will work on arm64
> too.
> 
> Some of these will be needed in the upcoming mshv driver code (for
> Linux as root partition on Hyper-V).

Previously, Linux as the root partition on Hyper-V was x86 only, which is
why the code is currently under arch/x86. So evidently the mshv driver
is being expanded to support both x86 and arm64, correct? Assuming
that's the case, I have some thoughts about how the source code should
be organized and built. It's probably best to get this right to start with so
it doesn't need to be changed again.

* Patch 2 of this series moves hv_call_deposit_pages() and
   hv_call_create_vp() to common code, but does not move
   hv_call_add_logical_proc(). All three are used together, so
   I'm wondering why hv_call_add_logical_proc() isn't moved.

* These three functions were originally put in a separate source
   code file because of being specific to running in the root partition,
   and not needed for generic Linux guest support. I think there's
   value in keeping them in a separate file, rather than merging them
   into hv_common.c. Maybe just move the entire hv_proc.c file?
   And then later, perhaps move the entire irqdomain.c file as well?
   There's also an interesting question of whether to move them into
   drivers/hv, or create a new directory virt/hyperv. Hyper-V support
   started out 15 years ago structured as a driver, hence "drivers/hv".
   But over the time, the support has become significantly more than
   just a driver, so "virt/hyperv" might be a better location for
   non-driver code that had previously been under arch/x86 but is
   now common to all architectures.

* Today, the code for running in the root partition is built along
   with the rest of the Hyper-V support, and so is present in kernels
   built for normal Linux guests on Hyper-V. I haven't thought about
   all the implications, but perhaps there's value in having a CONFIG
   option to build for the root partition, so that code can be dropped
   from normal kernels. There's a significant amount of new code still
   to come for mshv that could be excluded from normal guests in this
   way. Also, the tests of the hv_root_partition variable could be
   changed to a function the compiler detects is always "false" in a
   kernel built without the CONFIG option, in which case it can drop
   the code for where hv_root_partition is "true".

* The code currently in hv_proc.c is built for x86 only, and validly
   assumes the page size is 4K. But when the code moves to be
   common across architectures, that assumption is no longer
   valid in the general case. Perhaps the intent is that kernels for
   the root partition should always be built with page size 4K on
   arm64, but nothing enforces that intent. Personally, I think the code
   should be made to work with page sizes other than 4K so as to not
   leave technical debt. But I realize you may have other priorities. If
   there were a CONFIG option for building for the root partition,
   that option could be setup to enforce the 4K page size on arm64.

Anyway, thinking through these decisions up front could avoid
the need for additional moves later on.

Michael

> So this is a good time to move
> them to hv_common.c.
> 
> Signed-off-by: Nuno Das Neves <nudasnev@...rosoft.com>
> 
> Nuno Das Neves (2):
>   hyperv: Move hv_current_partition_id to arch-generic code
>   hyperv: Move create_vp and deposit_pages hvcalls to hv_common.c
> 
>  arch/arm64/hyperv/mshyperv.c    |   3 +
>  arch/x86/hyperv/hv_init.c       |  25 +----
>  arch/x86/hyperv/hv_proc.c       | 144 ---------------------------
>  arch/x86/include/asm/mshyperv.h |   4 -
>  drivers/hv/hv_common.c          | 168 ++++++++++++++++++++++++++++++++
>  include/asm-generic/mshyperv.h  |   4 +
>  6 files changed, 176 insertions(+), 172 deletions(-)
> 
> --
> 2.34.1

Powered by blists - more mailing lists