| Message ID | 1727985064-18362-1-git-send-email-nunodasneves@linux.microsoft.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add new headers for Hyper-V Dom0 | expand |
On Thu, Oct 03, 2024 at 12:50:59PM -0700, Nuno Das Neves wrote: > 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. It goes without saying that we need to make sure KVM still builds correctly after this series. Please make sure to test that. Thanks. Wei.
From: Nuno Das Neves <nunodasneves@linux.microsoft.com> 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. > > An intermediary header "hv_defs.h" is introduced to conditionally > include either hyperv-tlfs.h or hvhdk.h. This is required because > several headers which today include hyperv-tlfs.h, are shared > between Hyper-V and KVM code (e.g. mshyperv.h). Have you considered user space code that uses include/linux/hyperv.h? Which of the two schemes will it use? That code needs to compile correctly on x86 and ARM64 after your changes. User space code includes the separate DPDK project, and some of the tools in the kernel tree under tools/hv. Anything that uses the uio_hv_generic.c driver falls into this category. I think there's also user space code that is built for vDSO that might pull in the .h files you are modifying. There are in-progress patches dealing with vDSO include files, such as [1]. My general comment on vDSO is to be careful in making #include file changes that it uses, but I'm not knowledgeable enough on how vDSO is built to give specific guidance. :-( Michael [1] https://lore.kernel.org/lkml/20241010135146.181175-1-vincenzo.frascino@arm.com/ > > Summary: > Patch 1-2: Cleanup patches > Patch 3: Add the new headers (hvhdk.h, etc..) in include/hyperv/ > Patch 4: Add hv_defs.h and use it in mshyperv.h, svm.h, > hyperv_timer.h > Patch 5: Switch to the new headers, only in Hyper-V code > > Nuno Das Neves (5): > hyperv: Move hv_connection_id to hyperv-tlfs.h > hyperv: Remove unnecessary #includes > hyperv: Add new Hyper-V headers > hyperv: Add hv_defs.h to conditionally include hyperv-tlfs.h or > hvhdk.h > hyperv: Use hvhdk.h instead of hyperv-tlfs.h in Hyper-V code > > arch/arm64/hyperv/hv_core.c | 3 +- > arch/arm64/hyperv/mshyperv.c | 1 + > arch/arm64/include/asm/mshyperv.h | 2 +- > arch/x86/entry/vdso/vma.c | 1 + > arch/x86/hyperv/hv_apic.c | 2 +- > arch/x86/hyperv/hv_init.c | 3 +- > arch/x86/hyperv/hv_proc.c | 4 +- > arch/x86/hyperv/hv_spinlock.c | 1 + > arch/x86/hyperv/hv_vtl.c | 1 + > arch/x86/hyperv/irqdomain.c | 1 + > arch/x86/hyperv/ivm.c | 2 +- > arch/x86/hyperv/mmu.c | 2 +- > arch/x86/hyperv/nested.c | 2 +- > arch/x86/include/asm/kvm_host.h | 1 - > arch/x86/include/asm/mshyperv.h | 3 +- > arch/x86/include/asm/svm.h | 2 +- > arch/x86/include/asm/vdso/gettimeofday.h | 1 + > arch/x86/kernel/cpu/mshyperv.c | 2 +- > arch/x86/kernel/cpu/mtrr/generic.c | 1 + > arch/x86/kvm/vmx/vmx_onhyperv.h | 1 - > arch/x86/mm/pat/set_memory.c | 2 - > drivers/clocksource/hyperv_timer.c | 2 +- > drivers/hv/channel.c | 1 + > drivers/hv/channel_mgmt.c | 1 + > drivers/hv/connection.c | 1 + > drivers/hv/hv.c | 1 + > drivers/hv/hv_balloon.c | 5 +- > drivers/hv/hv_common.c | 2 +- > drivers/hv/hv_kvp.c | 1 - > drivers/hv/hv_snapshot.c | 1 - > drivers/hv/hv_util.c | 1 + > drivers/hv/hyperv_vmbus.h | 1 - > drivers/hv/ring_buffer.c | 1 + > drivers/hv/vmbus_drv.c | 1 + > drivers/iommu/hyperv-iommu.c | 1 + > drivers/net/hyperv/netvsc.c | 1 + > drivers/pci/controller/pci-hyperv.c | 1 + > include/asm-generic/hyperv-tlfs.h | 9 + > include/asm-generic/mshyperv.h | 2 +- > include/clocksource/hyperv_timer.h | 2 +- > include/hyperv/hv_defs.h | 29 + > include/hyperv/hvgdk.h | 66 ++ > include/hyperv/hvgdk_ext.h | 46 + > include/hyperv/hvgdk_mini.h | 1212 ++++++++++++++++++++++ > include/hyperv/hvhdk.h | 733 +++++++++++++ > include/hyperv/hvhdk_mini.h | 310 ++++++ > include/linux/hyperv.h | 12 +- > net/vmw_vsock/hyperv_transport.c | 1 - > 48 files changed, 2442 insertions(+), 40 deletions(-) > create mode 100644 include/hyperv/hv_defs.h > create mode 100644 include/hyperv/hvgdk.h > create mode 100644 include/hyperv/hvgdk_ext.h > create mode 100644 include/hyperv/hvgdk_mini.h > create mode 100644 include/hyperv/hvhdk.h > create mode 100644 include/hyperv/hvhdk_mini.h > > -- > 2.34.1 >
On 10/10/24 11:21, Michael Kelley wrote: > From: Nuno Das Neves <nunodasneves@linux.microsoft.com> 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
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@linux.microsoft.com> 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
On 10/10/2024 11:21 AM, Michael Kelley wrote: > From: Nuno Das Neves <nunodasneves@linux.microsoft.com> Sent: Thursday, October 3, 2024 12:51 PM >>>> An intermediary header "hv_defs.h" is introduced to conditionally >> include either hyperv-tlfs.h or hvhdk.h. This is required because >> several headers which today include hyperv-tlfs.h, are shared >> between Hyper-V and KVM code (e.g. mshyperv.h). > > Have you considered user space code that uses > include/linux/hyperv.h? Which of the two schemes will it use? That code > needs to compile correctly on x86 and ARM64 after your changes. > User space code includes the separate DPDK project, and some of the > tools in the kernel tree under tools/hv. Anything that uses the > uio_hv_generic.c driver falls into this category. > Unless I misunderstand something, the uapi code isn't affected at all by this patch set. e.g. the code in tools/hv uses include/uapi/linux/hyperv.h, which doesn't include any other Hyper-V headers. I'm not aware of how the DPDK project uses the Hyper-V definitions, but if it is getting headers from uapi it should also be unaffected. > I think there's also user space code that is built for vDSO that might pull > in the .h files you are modifying. There are in-progress patches dealing > with vDSO include files, such as [1]. My general comment on vDSO > is to be careful in making #include file changes that it uses, but I'm > not knowledgeable enough on how vDSO is built to give specific > guidance. :-( > Hmm, interesting, looks like it does get used by userspace. The tsc page is mapped into userspace in vdso.vma.c, and read in vdso/gettimeofday.h. That is unexpected for me, since these things aren't in uapi. However I don't anticipate a problem. The definitions used haven't changed, just the headers they are included from. Thanks Nuno > Michael > > [1] https://lore.kernel.org/lkml/20241010135146.181175-1-vincenzo.frascino@arm.com/ > >> >> Summary: >> Patch 1-2: Cleanup patches >> Patch 3: Add the new headers (hvhdk.h, etc..) in include/hyperv/ >> Patch 4: Add hv_defs.h and use it in mshyperv.h, svm.h, >> hyperv_timer.h >> Patch 5: Switch to the new headers, only in Hyper-V code >> >> Nuno Das Neves (5): >> hyperv: Move hv_connection_id to hyperv-tlfs.h >> hyperv: Remove unnecessary #includes >> hyperv: Add new Hyper-V headers >> hyperv: Add hv_defs.h to conditionally include hyperv-tlfs.h or >> hvhdk.h >> hyperv: Use hvhdk.h instead of hyperv-tlfs.h in Hyper-V code >> >> arch/arm64/hyperv/hv_core.c | 3 +- >> arch/arm64/hyperv/mshyperv.c | 1 + >> arch/arm64/include/asm/mshyperv.h | 2 +- >> arch/x86/entry/vdso/vma.c | 1 + >> arch/x86/hyperv/hv_apic.c | 2 +- >> arch/x86/hyperv/hv_init.c | 3 +- >> arch/x86/hyperv/hv_proc.c | 4 +- >> arch/x86/hyperv/hv_spinlock.c | 1 + >> arch/x86/hyperv/hv_vtl.c | 1 + >> arch/x86/hyperv/irqdomain.c | 1 + >> arch/x86/hyperv/ivm.c | 2 +- >> arch/x86/hyperv/mmu.c | 2 +- >> arch/x86/hyperv/nested.c | 2 +- >> arch/x86/include/asm/kvm_host.h | 1 - >> arch/x86/include/asm/mshyperv.h | 3 +- >> arch/x86/include/asm/svm.h | 2 +- >> arch/x86/include/asm/vdso/gettimeofday.h | 1 + >> arch/x86/kernel/cpu/mshyperv.c | 2 +- >> arch/x86/kernel/cpu/mtrr/generic.c | 1 + >> arch/x86/kvm/vmx/vmx_onhyperv.h | 1 - >> arch/x86/mm/pat/set_memory.c | 2 - >> drivers/clocksource/hyperv_timer.c | 2 +- >> drivers/hv/channel.c | 1 + >> drivers/hv/channel_mgmt.c | 1 + >> drivers/hv/connection.c | 1 + >> drivers/hv/hv.c | 1 + >> drivers/hv/hv_balloon.c | 5 +- >> drivers/hv/hv_common.c | 2 +- >> drivers/hv/hv_kvp.c | 1 - >> drivers/hv/hv_snapshot.c | 1 - >> drivers/hv/hv_util.c | 1 + >> drivers/hv/hyperv_vmbus.h | 1 - >> drivers/hv/ring_buffer.c | 1 + >> drivers/hv/vmbus_drv.c | 1 + >> drivers/iommu/hyperv-iommu.c | 1 + >> drivers/net/hyperv/netvsc.c | 1 + >> drivers/pci/controller/pci-hyperv.c | 1 + >> include/asm-generic/hyperv-tlfs.h | 9 + >> include/asm-generic/mshyperv.h | 2 +- >> include/clocksource/hyperv_timer.h | 2 +- >> include/hyperv/hv_defs.h | 29 + >> include/hyperv/hvgdk.h | 66 ++ >> include/hyperv/hvgdk_ext.h | 46 + >> include/hyperv/hvgdk_mini.h | 1212 ++++++++++++++++++++++ >> include/hyperv/hvhdk.h | 733 +++++++++++++ >> include/hyperv/hvhdk_mini.h | 310 ++++++ >> include/linux/hyperv.h | 12 +- >> net/vmw_vsock/hyperv_transport.c | 1 - >> 48 files changed, 2442 insertions(+), 40 deletions(-) >> create mode 100644 include/hyperv/hv_defs.h >> create mode 100644 include/hyperv/hvgdk.h >> create mode 100644 include/hyperv/hvgdk_ext.h >> create mode 100644 include/hyperv/hvgdk_mini.h >> create mode 100644 include/hyperv/hvhdk.h >> create mode 100644 include/hyperv/hvhdk_mini.h >> >> -- >> 2.34.1 >> >
From: Nuno Das Neves <nunodasneves@linux.microsoft.com> Sent: Tuesday, October 22, 2024 5:51 PM > > On 10/10/2024 11:21 AM, Michael Kelley wrote: > > [snip] > > Have you considered user space code that uses > > include/linux/hyperv.h? Which of the two schemes will it use? That code > > needs to compile correctly on x86 and ARM64 after your changes. > > User space code includes the separate DPDK project, and some of the > > tools in the kernel tree under tools/hv. Anything that uses the > > uio_hv_generic.c driver falls into this category. > > > Unless I misunderstand something, the uapi code isn't affected at all > by this patch set. e.g. the code in tools/hv uses include/uapi/linux/hyperv.h, > which doesn't include any other Hyper-V headers. > > I'm not aware of how the DPDK project uses the Hyper-V definitions, but if it > is getting headers from uapi it should also be unaffected. You are right. My mistake. User space code based on uio_hv_generic.c maps the VMBus ring buffers into user space, and I thought that code was pulling "struct hv_ring_buffer" from include/linux/hyperv.h file. But DPDK and the tools/hv code each have their own completely separate header file with the equivalent of "struct hv_ring_buffer". Duplicating the ring buffer structure in multiple places probably isn't ideal, but the decoupling helps in this case. ;-) > > > I think there's also user space code that is built for vDSO that might pull > > in the .h files you are modifying. There are in-progress patches dealing > > with vDSO include files, such as [1]. My general comment on vDSO > > is to be careful in making #include file changes that it uses, but I'm > > not knowledgeable enough on how vDSO is built to give specific > > guidance. :-( > > > Hmm, interesting, looks like it does get used by userspace. The tsc page > is mapped into userspace in vdso.vma.c, and read in vdso/gettimeofday.h. > > That is unexpected for me, since these things aren't in uapi. However I don't > anticipate a problem. The definitions used haven't changed, just the headers > they are included from. > Fair enough. I don't know enough about vDSO user space to add anything helpful. Michael
From: Nuno Das Neves <nunodasneves@linux.microsoft.com> Sent: Tuesday, October 22, 2024 5:04 PM > > 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@linux.microsoft.com> 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. Doing big changes incrementally is certainly useful and common enough in kernel development. But having two sets of header files that define the same thing, for use in two different parts of the code tree, seems a bit off the beaten path. I don’t see that there would be significant risk in doing KVM at the same time. But the KVM folks should weigh in on this. Just my $.02 worth, and I won't object whichever way you go. Michael > > > > 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
On 10/3/2024 12:50 PM, Nuno Das Neves wrote: > 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. > > An intermediary header "hv_defs.h" is introduced to conditionally > include either hyperv-tlfs.h or hvhdk.h. This is required because > several headers which today include hyperv-tlfs.h, are shared > between Hyper-V and KVM code (e.g. mshyperv.h). > > Summary: > Patch 1-2: Cleanup patches > Patch 3: Add the new headers (hvhdk.h, etc..) in include/hyperv/ > Patch 4: Add hv_defs.h and use it in mshyperv.h, svm.h, > hyperv_timer.h > Patch 5: Switch to the new headers, only in Hyper-V code > > Nuno Das Neves (5): > hyperv: Move hv_connection_id to hyperv-tlfs.h > hyperv: Remove unnecessary #includes > hyperv: Add new Hyper-V headers > hyperv: Add hv_defs.h to conditionally include hyperv-tlfs.h or > hvhdk.h > hyperv: Use hvhdk.h instead of hyperv-tlfs.h in Hyper-V code > What is the model for Hyper-V code that has both guest and host roles where the corresponding hypercalls are available for both? As I understand it, those are supposed to be in hvgdk*.h. For a specific example, IOMMU hypercalls can operate on stage 2 or stage 1 translations depending on the role of the (hyper) caller and the input values provided. Should a driver using these hypercalls import both hvhdk* and hvgdk*? What about hyperv-tlfs? Patches 4 and 5 seem to draw a bright line between host and guest roles while the reality is more gray. Please do correct me if I'm wrong here, perhaps the picture would be clearer if Stas' suggestion of a new header file is implemented. Thanks, Easwar
On 10/31/2024 12:05 PM, Easwar Hariharan wrote: > On 10/3/2024 12:50 PM, Nuno Das Neves wrote: >> 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. >> >> An intermediary header "hv_defs.h" is introduced to conditionally >> include either hyperv-tlfs.h or hvhdk.h. This is required because >> several headers which today include hyperv-tlfs.h, are shared >> between Hyper-V and KVM code (e.g. mshyperv.h). >> >> Summary: >> Patch 1-2: Cleanup patches >> Patch 3: Add the new headers (hvhdk.h, etc..) in include/hyperv/ >> Patch 4: Add hv_defs.h and use it in mshyperv.h, svm.h, >> hyperv_timer.h >> Patch 5: Switch to the new headers, only in Hyper-V code >> >> Nuno Das Neves (5): >> hyperv: Move hv_connection_id to hyperv-tlfs.h >> hyperv: Remove unnecessary #includes >> hyperv: Add new Hyper-V headers >> hyperv: Add hv_defs.h to conditionally include hyperv-tlfs.h or >> hvhdk.h >> hyperv: Use hvhdk.h instead of hyperv-tlfs.h in Hyper-V code >> Hi Easwar, thanks for the questions. I will attempt to clarify. > > What is the model for Hyper-V code that has both guest and host roles > where the corresponding hypercalls are available for both? As I > understand it, those are supposed to be in hvgdk*.h. > It's true that the naming of the files implies hvgdk*.h is for guests, and hvhdk*.h (which includes hvgdk*.h), is for hosts/dom0. But I would only take that as a rough guide. The real reason for keeping these names is to make it a easier to copy and maintain the definitions from the Windows code into Linux, by keeping the provenance of exactly where they came from. > For a specific example, IOMMU hypercalls can operate on stage 2 or stage > 1 translations depending on the role of the (hyper) caller and the input > values provided. Should a driver using these hypercalls import both > hvhdk* and hvgdk*? What about hyperv-tlfs? > I'd recommend importing hvhdk.h since it contains everything you need (including hvgdk*.h). The goal of this patchset is to move away from hyperv-tlfs.h, because by definition it should only contain definitions from the TLFS document. > Patches 4 and 5 seem to draw a bright line between host and guest roles > while the reality is more gray. Please do correct me if I'm wrong here, > perhaps the picture would be clearer if Stas' suggestion of a new header > file is implemented. > Patches 4 and 5 introduce the new headers in a way that avoids any potential impact on KVM and other non-Microsoft-maintained code. The 'line' is not between guest and host, but between Microsoft-maintained and non-Microsoft-maintained code. Thanks, Nuno > Thanks, > Easwar
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. An intermediary header "hv_defs.h" is introduced to conditionally include either hyperv-tlfs.h or hvhdk.h. This is required because several headers which today include hyperv-tlfs.h, are shared between Hyper-V and KVM code (e.g. mshyperv.h). Summary: Patch 1-2: Cleanup patches Patch 3: Add the new headers (hvhdk.h, etc..) in include/hyperv/ Patch 4: Add hv_defs.h and use it in mshyperv.h, svm.h, hyperv_timer.h Patch 5: Switch to the new headers, only in Hyper-V code Nuno Das Neves (5): hyperv: Move hv_connection_id to hyperv-tlfs.h hyperv: Remove unnecessary #includes hyperv: Add new Hyper-V headers hyperv: Add hv_defs.h to conditionally include hyperv-tlfs.h or hvhdk.h hyperv: Use hvhdk.h instead of hyperv-tlfs.h in Hyper-V code arch/arm64/hyperv/hv_core.c | 3 +- arch/arm64/hyperv/mshyperv.c | 1 + arch/arm64/include/asm/mshyperv.h | 2 +- arch/x86/entry/vdso/vma.c | 1 + arch/x86/hyperv/hv_apic.c | 2 +- arch/x86/hyperv/hv_init.c | 3 +- arch/x86/hyperv/hv_proc.c | 4 +- arch/x86/hyperv/hv_spinlock.c | 1 + arch/x86/hyperv/hv_vtl.c | 1 + arch/x86/hyperv/irqdomain.c | 1 + arch/x86/hyperv/ivm.c | 2 +- arch/x86/hyperv/mmu.c | 2 +- arch/x86/hyperv/nested.c | 2 +- arch/x86/include/asm/kvm_host.h | 1 - arch/x86/include/asm/mshyperv.h | 3 +- arch/x86/include/asm/svm.h | 2 +- arch/x86/include/asm/vdso/gettimeofday.h | 1 + arch/x86/kernel/cpu/mshyperv.c | 2 +- arch/x86/kernel/cpu/mtrr/generic.c | 1 + arch/x86/kvm/vmx/vmx_onhyperv.h | 1 - arch/x86/mm/pat/set_memory.c | 2 - drivers/clocksource/hyperv_timer.c | 2 +- drivers/hv/channel.c | 1 + drivers/hv/channel_mgmt.c | 1 + drivers/hv/connection.c | 1 + drivers/hv/hv.c | 1 + drivers/hv/hv_balloon.c | 5 +- drivers/hv/hv_common.c | 2 +- drivers/hv/hv_kvp.c | 1 - drivers/hv/hv_snapshot.c | 1 - drivers/hv/hv_util.c | 1 + drivers/hv/hyperv_vmbus.h | 1 - drivers/hv/ring_buffer.c | 1 + drivers/hv/vmbus_drv.c | 1 + drivers/iommu/hyperv-iommu.c | 1 + drivers/net/hyperv/netvsc.c | 1 + drivers/pci/controller/pci-hyperv.c | 1 + include/asm-generic/hyperv-tlfs.h | 9 + include/asm-generic/mshyperv.h | 2 +- include/clocksource/hyperv_timer.h | 2 +- include/hyperv/hv_defs.h | 29 + include/hyperv/hvgdk.h | 66 ++ include/hyperv/hvgdk_ext.h | 46 + include/hyperv/hvgdk_mini.h | 1212 ++++++++++++++++++++++ include/hyperv/hvhdk.h | 733 +++++++++++++ include/hyperv/hvhdk_mini.h | 310 ++++++ include/linux/hyperv.h | 12 +- net/vmw_vsock/hyperv_transport.c | 1 - 48 files changed, 2442 insertions(+), 40 deletions(-) create mode 100644 include/hyperv/hv_defs.h create mode 100644 include/hyperv/hvgdk.h create mode 100644 include/hyperv/hvgdk_ext.h create mode 100644 include/hyperv/hvgdk_mini.h create mode 100644 include/hyperv/hvhdk.h create mode 100644 include/hyperv/hvhdk_mini.h