Re: [EXTERNAL] RE: [PATCH 3/5] hyperv: Add new Hyper-V headers

[MUKESH RATHOR]

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