On 10/10/24 11:21, Michael Kelley wrote: > From: Nuno Das Neves <nunodasneves@xxxxxxxxxxxxxxxxxxx> 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? > 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. 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
