"Michael Kelley (EOSG)" <Michael.H.Kelley@xxxxxxxxxxxxx> writes: >> >> > Removing definitions from userspace api isn't a good idea. >> >> > >> >> > I have no idea why hyper.h is a userspace api, though -- Linux doesn't >> >> > define any of those, so we could copy the definitions to a private >> >> > header, rename, and never look at this file again. >> >> >> >> That was a thinko when it was moved to uapi, and it has already been >> >> identified as a problem, so now QEMU has its own header with the >> >> definitions it needs, and I'm unaware of any other userspace project >> >> that depends on this stuff. So I've been planning to remove it from >> >> uapi but still haven't got around to posting the patch :( >> > >> > Great, let's be bold here. >> >> asm/hyperv.h is not uapi. >> >> I would include a patch renaming arch/x86/include/uapi/asm/hyperv.h to >> arch/x86/include/asm/hyperv.h but we already have 'mshyperv.h' there and >> I don't quite understand the difference. We can either merge them or >> come up with a rule distinguishing them. >> >> K. Y., Michael, what do you think? > > Good timing for this topic, as I'm now looking at cloning these two > files into the arch/arm64 tree for Hyper-V on ARM64. It would be great > to get a plan agreed on so I can be consistent on the arm64 side. > > I would suggest keeping two files: one with just the data structures and > #defines that come from the Hyper-V Top-Level Functional Spec (TLFS), > and the other with additional data structures, macros, function prototypes, > etc. that are specific to Linux guest code. uapi/asm/hyperv.h is already > the first one, and asm/mshyperv.h is mostly the second one, though it has > some things that should probably move to the first one. There are also a > few stray definitions from the Hyper-V TLFS in drivers/pci/host/pci-hyperv.c > (HVCALL_RETARGET_INTERRUPT and HV_PARTITION_ID_SELF, for example) > that really belong in the first file. > > And since we're already changing the location of the first file, let's rename > it to hyperv-tlfs.h or something similar. > Sounds good, I'll add a patch or two to my eVMCS series. Thanks! -- Vitaly
