Re: [PATCH v5 3/5] hyperv: Enable the hypercall output page for the VTL mode

[Roman Kisel <romank@linux.microsoft.com>]

On 1/6/2025 11:32 AM, Stanislav Kinsburskii wrote:
> On Mon, Jan 06, 2025 at 10:11:16AM -0800, Roman Kisel wrote:
[...]s

> From my POV a decision between a unified approach and interim solutions
> in upstream should usually be resolved in favor of the former.
> Given there are different stake holders in VTL code integration, I'd
> suggest we step back a bit and think about how to proceed with the
> overall design.
I don't see any compelling reason for stalling this fix and think for
no one knows how long. What is going to be fixed is clear, and it has
not been demonstrated what is going to be broken when this change is
merged.

> 
> In my opinion, although I undestand why Underhill project decided to
> come up with the original VTL kernels separation during build time, it's
> time to reconsider this approach and to come up with a more generic
> design, supporting booting the same kernel in different VTLs.
"The same kernel" means supporting ACPI/UEFI for VTL0, VTL1, VTL2 as
otherwise VTL0 won't boot. But why would VTL>0 even consider relying on
ACPI or compiling it in? I would fix your broad assertion with adding
one constraint: share as much Hyper-V code as possible, booting is not
expected, rather refuse building.

> 
> The major reason for this is that LVBS project relies on binary
> compatibility of the kernels running in different VTLs.
> The simplest way to provide such a guarantee in both development and
> deployment is to run the same kernel in both VTLs.

OpenHCL aka Underhill is the only shipping product relying on
the code in question (others might be dom0 and LVBS). What the LVBS
project relies on might change any number of times any day before it
ships. OpenHCL works for customers and slicing and dicing it ought to
be well thought through.

> Not having this ability will require carefull crafting of both the
> kernels upon build, making kexec servicing of such kernels in production
> complicated and error prone.

Too vague, imho. I'd respond that "careful crafting" shouldn't lead to
being complicated and error prone as long as it's automatic and, well,
careful.

It is harder and harder to me to see how enabling the hypercall output
page is related to where the discussion has drifted. My claims are:

* enabling the hypercall output page poses no harm (doesn't break hyper-
next),
* allows to bring the code to the clear and concise form of getting a VP
register.

Can you refute any of that?

> 
> Thanks,
> Stas

-- 
Thank you,
Roman