On 1/6/2025 9:11 AM, Stanislav Kinsburskii wrote:
On Fri, Jan 03, 2025 at 01:39:29PM -0800, Roman Kisel wrote:
[...]
The issue is that when you boot the same kernel in both VTL0 and VTL1+,
the pages will be allocated in any case (root or guest, VTL0 or VTL1+).
I think we share we same beliefs: use common code as much as possible.
Strategically, one day, there will be the kernel being able to boot
(or at the very minimum share the Hyper-V code for) VTL0, VTL1 (LVBS)
and VTL2 (OpenHCL). It is not today, though: VTL0 relies on ACPI|BIOS,
VTL2 relies on DeviceTree, and VTL1 boot configuration comes off as
a bit ad-hoc from my read of https://github.com/heki-linux/lvbs-linux,
and working with the LVBS folks on debugging that.
Can that day of the grand VTL code unification be tomorrow, or next
week, or next month, or maybe next year, what is the option you leaning
towards?
To me, it seems, that's not even the next month. Let us take a look
at how much ink is being spent to just fix a garden variety function.
On the meta-level that might mean some _fundamental work_ is needed to
provide a _robust foundation_ to built upon, such as removing the if
statements and #ifdef's we're debating about to let the general case
shine through.
Tactically, imo, a staged approach might give more velocity and
coverage instead of fixing the world in this small patch set. I would
not want to increase the potential "blast radius" of the change.
As it stands, it is pretty well-contained.
All told, it might be prudent to focus on the task at hand - fix the
function in question to enable building on that, e.g. proposing the v4
of the ARM64 VTL mode patches, and more of what we have in
https://github.com/microsoft/OHCL-Linux-Kernel.
Once we take that small step to fix the hyperv-next tree, someone could
propose removing the conditions for allocating the output page —-- or,
perhaps, suggest an entirely new & vastly better solution to handling
the hypercall output page. IMHO, that would enable adding features via
relying on more generic code rather than further complicating the web
of conditional statements and conditional compilation.
Also, there are other places in the code, where braching needs to be done
differently depending in on which VTL the execution is happening in.
I think, there are two possible paths we can take here.
The first one is when the checks are done during compilation. In this case
the kernel should explicitly fail to boot in VTL0 if compiled for VTL1+
and vice versa.
The second one if to make checks in runtime and let the same kernel boot
differently in different VTLs.
Thoughts?
Stas
Thanks,
Stas
hyperv_pcpu_output_arg = alloc_percpu(void *);
BUG_ON(!hyperv_pcpu_output_arg);
}
@@ -435,7 +435,7 @@ int hv_common_cpu_init(unsigned int cpu)
void **inputarg, **outputarg;
u64 msr_vp_index;
gfp_t flags;
- int pgcount = hv_root_partition ? 2 : 1;
+ const int pgcount = (hv_root_partition || IS_ENABLED(CONFIG_HYPERV_VTL_MODE)) ? 2 : 1;
void *mem;
int ret;
@@ -453,7 +453,7 @@ int hv_common_cpu_init(unsigned int cpu)
if (!mem)
return -ENOMEM;
- if (hv_root_partition) {
+ if (hv_root_partition || IS_ENABLED(CONFIG_HYPERV_VTL_MODE)) {
outputarg = (void **)this_cpu_ptr(hyperv_pcpu_output_arg);
*outputarg = (char *)mem + HV_HYP_PAGE_SIZE;
}
--
2.34.1
--
Thank you,
Roman
--
Thank you,
Roman
