Michael - sorry for the delay, I just got back from vacation. On 10/10/2024 6:34 PM, MUKESH RATHOR wrote: > > > 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? 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. > > 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. > > 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
