RE: [EXTERNAL] RE: [PATCH 0/5] Add new headers for Hyper-V Dom0

From: Nuno Das Neves <redacted> Sent: Tuesday, October 22, 2024 5:04 PM

Michael - sorry for the delay, I just got back from vacation.

On 10/10/2024 6:34 PM, MUKESH RATHOR wrote:

quoted

On 10/10/24 11:21, Michael Kelley wrote:
 > From: Nuno Das Neves [off-list ref] Sent:
Thursday, October 3, 2024 12:51 PM
 >>
 >> To support Hyper-V Dom0 (aka Linux as root partition), many new
 >> definitions are required.
 >>
 >> The plan going forward is to directly import headers from
 >> Hyper-V. This is a more maintainable way to import definitions
 >> rather than via the TLFS doc. This patch series introduces
 >> new headers (hvhdk.h, hvgdk.h, etc, see patch #3) directly
 >> derived from Hyper-V code.
 >>
 >> This patch series replaces hyperv-tlfs.h with hvhdk.h, but only
 >> in Microsoft-maintained Hyper-V code where they are needed. This
 >> leaves the existing hyperv-tlfs.h in use elsewhere - notably for
 >> Hyper-V enlightenments on KVM guests.
 >
 > Could you elaborate on why the bifurcation is necessary? Is it an
 > interim step until the KVM code can use the new scheme as well?

It's not strictly necessary. We chose this approach in order to
minimize any potential impact on KVM and other non-Microsoft-
maintained code that uses hyperv-tlfs.h. As Mukesh mentioned below,
eventually it will be better if everyone uses the new headers.

Doing big changes incrementally is certainly useful and common enough
in kernel development. But having two sets of header files that define
the same thing, for use in two different parts of the code tree, seems
a bit off the beaten path. I don’t see that there would be significant
risk in doing KVM at the same time. But the KVM folks should weigh
in on this.

Just my $.02 worth, and I won't object whichever way you go.

Michael

quoted

 > Also, does "Hyper-V enlightenments on KVM guests" refer to
 > nested KVM running at L1 on an L0 Hyper-V, and supporting L2 guests?
 > Or is it the more general KVM support for mimicking Hyper-V for
 > the purposes of running Windows guests? From these patches, it
 > looks like your intention is for all KVM support for Hyper-V
 > functionality to continue to use the existing hyperv-tlfs.h file.

You're correct - "all KVM support for Hyper-V" is really what I meant.

quoted

Like it says above, we are creating new dom0 (root/host) support
that requires many new defs only available to dom0 and not any
guest. Hypervisor makes them publicly available via hv*dk files.

Ideally, someday everybody will use those, I hope we can move in
that direction, but I guess one step at a time. For now, KVM can
continue to use the tlfs file, and if there is no resistance, we
can move them to hv*dk files also as next step and obsolete the
single tlfs file.

Since headers are the ultimate source of truth, this will allow
better maintenance, better debug/support experience, and a more
stable stack. It also enforces non-leaking of data structs from
private header files (unfortunately has happened).

Thanks
-Mukesh

Thanks for providing the additional context, Mukesh.

Nuno