Hi Michael, I can answer some of the questions since I instigated this effort while ago (you might find old email chain/s). On 10/10/24 11:21, Michael Kelley wrote: > From: Nuno Das Neves <nunodasneves@xxxxxxxxxxxxxxxxxxx> Sent: Thursday, October 3, 2024 12:51 PM >> >> Add definitions needed for privileged Hyper-V partitions. >> >> These files are derived from headers exported from the hypervisor code. > > Could you elaborate on the naming conventions for the new files, > and the rules that govern what goes in what files? Specifically, > what is "hvgdk" vs. "hvhdk", and what are the _ext and _mini > suffixes? Even if the filenames are derived from Windows hvhdk : hyp host development kit hvgdk : hyp guest development kit IOW, hdk files include data structures for a privileged VM, aka dom0/root/host, and gdk targets an unprivileged VMs, ie, guests. The _mini implies target is host/guest kernel, and non-mini targets VMMs, but that appears more historic as over time things moved from kernel to user space. The hvgdk_ext was created for extended hypercalls. Please note, these headers are publicly exported by the hypervisor and consumed as is by Windows today (not sure about BSD and others), so changing them is prob not feasible. ... >> This is a step toward importing headers directly, similar to Xen public >> files in include/xen/interface/. > > I'm not understanding this statement. The new files in this patch > are obviously following Linux kernel coding style, with Linux kernel > types, etc. I'm guessing there was a lot of "busy work" to take > Windows Hyper-V code and make it look like Linux kernel code. :-( > What would "importing headers directly" look like, and how is this > an interim step? Correct, they are currently not directly imported. The coding style is different and also the hyp is not built using gcc/clang. So, we've some work to do before we can use them as is. For now, we have "mirrored" them manually enforcing Linux style. Going forward, we have to decide if we can use them as is (there is some precedent in linux for drivers including headers with different coding style) or we can auto convert them via some tool or we can keep them manual and modify them in sync with hyp modifying them. In any case, it should be rare operation. Matching them now allows us to get there. You are correct, it was "busy work", took me more than two weeks in addition to time Nuno also spent. > Also, it looks like these new files take a different approach for > instruction set architecture differences. There are inline #ifdef's > instead of the current method of having a common file, and then > architecture specific versions that include the common file. My > sense is that Linux kernel code prefers the current approach in > order to avoid #ifdef'ery, but maybe that's less practical when the > definitions are derived from Windows Hyper-V code. And with > only two architectures to deal with, the #ifdef's don't get > wild-and-crazy, which is good. Well, we are trying to keep them as close to the originals as possible. But now that linux support is here, we will work with the producers of these headers, ie, the hyp team, to make them more linux friendly going forward. Given there are other direct consumers of the headers, Windows/BSD/.., it won't be right away, as we'd have to coordinate and make sure all are happy. Hope that makes sense. Thanks, -Mukesh
