| Message ID | 1731018746-25914-1-git-send-email-nunodasneves@linux.microsoft.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add new headers for Hyper-V Dom0 | expand |
From: Nuno Das Neves <nunodasneves@linux.microsoft.com> Sent: Thursday, November 7, 2024 2:32 PM > > To support Hyper-V Dom0 (aka Linux as root partition), many new > definitions are required. Using "dom0" terminology here and in the Subject: line is likely to be confusing to folks who aren't intimately involved in Hyper-V work. Previous Linux kernel commit messages and code for running in the Hyper-V root partition use "root partition" terminology, and I couldn't find "dom0" having been used before. "root partition" would be more consistent, and it also matches the public documentation for Hyper-V. "dom0" is Xen specific terminology, and having it show up in Hyper-V patches would be confusing for the casual reader. I know "dom0" has been used internally at Microsoft as shorthand for "Hyper-V root partition", but it's probably best to completely avoid such shorthand in public Linux kernel patches and code. Just my $.02 .... > > The plan going forward is to directly import definitions from > Hyper-V code without waiting for them to land in the TLFS document. > This is a quicker and more maintainable way to import definitions, > and is a step toward the eventual goal of exporting headers directly > from Hyper-V for use in Linux. > > This patch series introduces new headers (hvhdk.h, hvgdk.h, etc, > see patch #3) derived directly from Hyper-V code. hyperv-tlfs.h is > replaced with hvhdk.h (which includes the other new headers) > everywhere. > > No functional change is expected. > > Summary: > Patch 1-2: Minor cleanup patches > Patch 3: Add the new headers (hvhdk.h, etc..) in include/hyperv/ > Patch 4: Switch to the new headers > > Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> > --- > Changelog: > v2: > - Rework the series to simply use the new headers everywhere > instead of fiddling around to keep hyperv-tlfs.h used in some > places, suggested by Michael Kelley and Easwar Hariharan Thanks! That should be simpler all around. Michael > - Fix compilation errors with some configs by adding missing > definitions and changing some names, thanks to Simon Horman for > catching those > - Add additional definitions to the new headers to support them now > replacing hyperv-tlfs.h everywhere > - Add additional context in the commit messages for patches #3 and #4 > - In patch #2, don't remove indirect includes. Only remove includes > which truly aren't used, suggested by Michael Kelley > > --- > Nuno Das Neves (4): > hyperv: Move hv_connection_id to hyperv-tlfs.h > hyperv: Clean up unnecessary #includes > hyperv: Add new Hyper-V headers in include/hyperv > hyperv: Switch from hyperv-tlfs.h to hyperv/hvhdk.h > > arch/arm64/hyperv/hv_core.c | 3 +- > arch/arm64/hyperv/mshyperv.c | 4 +- > arch/arm64/include/asm/mshyperv.h | 2 +- > arch/x86/hyperv/hv_apic.c | 1 - > arch/x86/hyperv/hv_init.c | 21 +- > arch/x86/hyperv/hv_proc.c | 3 +- > arch/x86/hyperv/ivm.c | 1 - > arch/x86/hyperv/mmu.c | 1 - > arch/x86/hyperv/nested.c | 2 +- > arch/x86/include/asm/kvm_host.h | 3 +- > arch/x86/include/asm/mshyperv.h | 3 +- > arch/x86/include/asm/svm.h | 2 +- > arch/x86/kernel/cpu/mshyperv.c | 2 +- > arch/x86/kvm/vmx/hyperv_evmcs.h | 2 +- > arch/x86/kvm/vmx/vmx_onhyperv.h | 2 +- > arch/x86/mm/pat/set_memory.c | 2 - > drivers/clocksource/hyperv_timer.c | 2 +- > drivers/hv/hv_balloon.c | 4 +- > drivers/hv/hv_common.c | 2 +- > drivers/hv/hv_kvp.c | 2 +- > drivers/hv/hv_snapshot.c | 2 +- > drivers/hv/hyperv_vmbus.h | 2 +- > include/asm-generic/hyperv-tlfs.h | 9 + > include/asm-generic/mshyperv.h | 2 +- > include/clocksource/hyperv_timer.h | 2 +- > include/hyperv/hvgdk.h | 303 +++++++ > include/hyperv/hvgdk_ext.h | 46 + > include/hyperv/hvgdk_mini.h | 1295 ++++++++++++++++++++++++++++ > include/hyperv/hvhdk.h | 733 ++++++++++++++++ > include/hyperv/hvhdk_mini.h | 310 +++++++ > include/linux/hyperv.h | 11 +- > net/vmw_vsock/hyperv_transport.c | 2 +- > 32 files changed, 2729 insertions(+), 52 deletions(-) > 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 11/10/2024 8:12 PM, Michael Kelley wrote: > From: Nuno Das Neves <nunodasneves@linux.microsoft.com> Sent: Thursday, November 7, 2024 2:32 PM >> >> To support Hyper-V Dom0 (aka Linux as root partition), many new >> definitions are required. > > Using "dom0" terminology here and in the Subject: line is likely to > be confusing to folks who aren't intimately involved in Hyper-V work. > Previous Linux kernel commit messages and code for running in the > Hyper-V root partition use "root partition" terminology, and I couldn't > find "dom0" having been used before. "root partition" would be more > consistent, and it also matches the public documentation for Hyper-V. > "dom0" is Xen specific terminology, and having it show up in Hyper-V > patches would be confusing for the casual reader. I know "dom0" has > been used internally at Microsoft as shorthand for "Hyper-V root > partition", but it's probably best to completely avoid such shorthand > in public Linux kernel patches and code. > > Just my $.02 .... > Noted - I will update the terminology in v3 and generally avoid "Dom0", except possibly by way of explanation (i.e. to compare it to Xen Dom0). Thanks Nuno >> >> The plan going forward is to directly import definitions from >> Hyper-V code without waiting for them to land in the TLFS document. >> This is a quicker and more maintainable way to import definitions, >> and is a step toward the eventual goal of exporting headers directly >> from Hyper-V for use in Linux. >> >> This patch series introduces new headers (hvhdk.h, hvgdk.h, etc, >> see patch #3) derived directly from Hyper-V code. hyperv-tlfs.h is >> replaced with hvhdk.h (which includes the other new headers) >> everywhere. >> >> No functional change is expected. >> >> Summary: >> Patch 1-2: Minor cleanup patches >> Patch 3: Add the new headers (hvhdk.h, etc..) in include/hyperv/ >> Patch 4: Switch to the new headers >> >> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> >> --- >> Changelog: >> v2: >> - Rework the series to simply use the new headers everywhere >> instead of fiddling around to keep hyperv-tlfs.h used in some >> places, suggested by Michael Kelley and Easwar Hariharan > > Thanks! That should be simpler all around. > > Michael > >> - Fix compilation errors with some configs by adding missing >> definitions and changing some names, thanks to Simon Horman for >> catching those >> - Add additional definitions to the new headers to support them now >> replacing hyperv-tlfs.h everywhere >> - Add additional context in the commit messages for patches #3 and #4 >> - In patch #2, don't remove indirect includes. Only remove includes >> which truly aren't used, suggested by Michael Kelley >> >> --- >> Nuno Das Neves (4): >> hyperv: Move hv_connection_id to hyperv-tlfs.h >> hyperv: Clean up unnecessary #includes >> hyperv: Add new Hyper-V headers in include/hyperv >> hyperv: Switch from hyperv-tlfs.h to hyperv/hvhdk.h >> >> arch/arm64/hyperv/hv_core.c | 3 +- >> arch/arm64/hyperv/mshyperv.c | 4 +- >> arch/arm64/include/asm/mshyperv.h | 2 +- >> arch/x86/hyperv/hv_apic.c | 1 - >> arch/x86/hyperv/hv_init.c | 21 +- >> arch/x86/hyperv/hv_proc.c | 3 +- >> arch/x86/hyperv/ivm.c | 1 - >> arch/x86/hyperv/mmu.c | 1 - >> arch/x86/hyperv/nested.c | 2 +- >> arch/x86/include/asm/kvm_host.h | 3 +- >> arch/x86/include/asm/mshyperv.h | 3 +- >> arch/x86/include/asm/svm.h | 2 +- >> arch/x86/kernel/cpu/mshyperv.c | 2 +- >> arch/x86/kvm/vmx/hyperv_evmcs.h | 2 +- >> arch/x86/kvm/vmx/vmx_onhyperv.h | 2 +- >> arch/x86/mm/pat/set_memory.c | 2 - >> drivers/clocksource/hyperv_timer.c | 2 +- >> drivers/hv/hv_balloon.c | 4 +- >> drivers/hv/hv_common.c | 2 +- >> drivers/hv/hv_kvp.c | 2 +- >> drivers/hv/hv_snapshot.c | 2 +- >> drivers/hv/hyperv_vmbus.h | 2 +- >> include/asm-generic/hyperv-tlfs.h | 9 + >> include/asm-generic/mshyperv.h | 2 +- >> include/clocksource/hyperv_timer.h | 2 +- >> include/hyperv/hvgdk.h | 303 +++++++ >> include/hyperv/hvgdk_ext.h | 46 + >> include/hyperv/hvgdk_mini.h | 1295 ++++++++++++++++++++++++++++ >> include/hyperv/hvhdk.h | 733 ++++++++++++++++ >> include/hyperv/hvhdk_mini.h | 310 +++++++ >> include/linux/hyperv.h | 11 +- >> net/vmw_vsock/hyperv_transport.c | 2 +- >> 32 files changed, 2729 insertions(+), 52 deletions(-) >> 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 11/10/24 20:12, Michael Kelley wrote: > From: Nuno Das Neves <nunodasneves@linux.microsoft.com> Sent: Thursday, November 7, 2024 2:32 PM >> >> To support Hyper-V Dom0 (aka Linux as root partition), many new >> definitions are required. > > Using "dom0" terminology here and in the Subject: line is likely to > be confusing to folks who aren't intimately involved in Hyper-V work. > Previous Linux kernel commit messages and code for running in the > Hyper-V root partition use "root partition" terminology, and I couldn't > find "dom0" having been used before. "root partition" would be more > consistent, and it also matches the public documentation for Hyper-V. > "dom0" is Xen specific terminology, and having it show up in Hyper-V > patches would be confusing for the casual reader. I know "dom0" has > been used internally at Microsoft as shorthand for "Hyper-V root > partition", but it's probably best to completely avoid such shorthand > in public Linux kernel patches and code. > > Just my $.02 .... Hi Michael, FWIW, hyperv team and us are using the term "dom0" more and more to avoid confusion between windows root and linux root, as dom0 is always linux root. I did a quick search, and "dom0" is neither copyrighted nor trademarked by xen, and I'm sure the fine folks there won't be offended. Hopefully, [Hyper-V] tag would reduce the confusion. Just my $0.1 Thanks, -Mukesh
From: Nuno Das Neves <nunodasneves@linux.microsoft.com> Sent: Monday, November 11, 2024 10:00 AM > > On 11/10/2024 8:12 PM, Michael Kelley wrote: > > From: Nuno Das Neves <nunodasneves@linux.microsoft.com> Sent: Thursday, November 7, 2024 2:32 PM > >> > >> To support Hyper-V Dom0 (aka Linux as root partition), many new > >> definitions are required. > > > > Using "dom0" terminology here and in the Subject: line is likely to > > be confusing to folks who aren't intimately involved in Hyper-V work. > > Previous Linux kernel commit messages and code for running in the > > Hyper-V root partition use "root partition" terminology, and I couldn't > > find "dom0" having been used before. "root partition" would be more > > consistent, and it also matches the public documentation for Hyper-V. > > "dom0" is Xen specific terminology, and having it show up in Hyper-V > > patches would be confusing for the casual reader. I know "dom0" has > > been used internally at Microsoft as shorthand for "Hyper-V root > > partition", but it's probably best to completely avoid such shorthand > > in public Linux kernel patches and code. > > > > Just my $.02 .... > > > > Noted - I will update the terminology in v3 and generally avoid "Dom0", > except possibly by way of explanation (i.e. to compare it to Xen Dom0). Yes, I'm good with comparing the Hyper-V root partition to Xen dom0 as part of an explanation. Michael > > Thanks > Nuno > > >> > >> The plan going forward is to directly import definitions from > >> Hyper-V code without waiting for them to land in the TLFS document. > >> This is a quicker and more maintainable way to import definitions, > >> and is a step toward the eventual goal of exporting headers directly > >> from Hyper-V for use in Linux. > >> > >> This patch series introduces new headers (hvhdk.h, hvgdk.h, etc, > >> see patch #3) derived directly from Hyper-V code. hyperv-tlfs.h is > >> replaced with hvhdk.h (which includes the other new headers) > >> everywhere. > >> > >> No functional change is expected. > >> > >> Summary: > >> Patch 1-2: Minor cleanup patches > >> Patch 3: Add the new headers (hvhdk.h, etc..) in include/hyperv/ > >> Patch 4: Switch to the new headers > >> > >> Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> > >> --- > >> Changelog: > >> v2: > >> - Rework the series to simply use the new headers everywhere > >> instead of fiddling around to keep hyperv-tlfs.h used in some > >> places, suggested by Michael Kelley and Easwar Hariharan > > > > Thanks! That should be simpler all around. > > > > Michael > > > >> - Fix compilation errors with some configs by adding missing > >> definitions and changing some names, thanks to Simon Horman for > >> catching those > >> - Add additional definitions to the new headers to support them now > >> replacing hyperv-tlfs.h everywhere > >> - Add additional context in the commit messages for patches #3 and #4 > >> - In patch #2, don't remove indirect includes. Only remove includes > >> which truly aren't used, suggested by Michael Kelley > >> > >> --- > >> Nuno Das Neves (4): > >> hyperv: Move hv_connection_id to hyperv-tlfs.h > >> hyperv: Clean up unnecessary #includes > >> hyperv: Add new Hyper-V headers in include/hyperv > >> hyperv: Switch from hyperv-tlfs.h to hyperv/hvhdk.h > >> > >> arch/arm64/hyperv/hv_core.c | 3 +- > >> arch/arm64/hyperv/mshyperv.c | 4 +- > >> arch/arm64/include/asm/mshyperv.h | 2 +- > >> arch/x86/hyperv/hv_apic.c | 1 - > >> arch/x86/hyperv/hv_init.c | 21 +- > >> arch/x86/hyperv/hv_proc.c | 3 +- > >> arch/x86/hyperv/ivm.c | 1 - > >> arch/x86/hyperv/mmu.c | 1 - > >> arch/x86/hyperv/nested.c | 2 +- > >> arch/x86/include/asm/kvm_host.h | 3 +- > >> arch/x86/include/asm/mshyperv.h | 3 +- > >> arch/x86/include/asm/svm.h | 2 +- > >> arch/x86/kernel/cpu/mshyperv.c | 2 +- > >> arch/x86/kvm/vmx/hyperv_evmcs.h | 2 +- > >> arch/x86/kvm/vmx/vmx_onhyperv.h | 2 +- > >> arch/x86/mm/pat/set_memory.c | 2 - > >> drivers/clocksource/hyperv_timer.c | 2 +- > >> drivers/hv/hv_balloon.c | 4 +- > >> drivers/hv/hv_common.c | 2 +- > >> drivers/hv/hv_kvp.c | 2 +- > >> drivers/hv/hv_snapshot.c | 2 +- > >> drivers/hv/hyperv_vmbus.h | 2 +- > >> include/asm-generic/hyperv-tlfs.h | 9 + > >> include/asm-generic/mshyperv.h | 2 +- > >> include/clocksource/hyperv_timer.h | 2 +- > >> include/hyperv/hvgdk.h | 303 +++++++ > >> include/hyperv/hvgdk_ext.h | 46 + > >> include/hyperv/hvgdk_mini.h | 1295 ++++++++++++++++++++++++++++ > >> include/hyperv/hvhdk.h | 733 ++++++++++++++++ > >> include/hyperv/hvhdk_mini.h | 310 +++++++ > >> include/linux/hyperv.h | 11 +- > >> net/vmw_vsock/hyperv_transport.c | 2 +- > >> 32 files changed, 2729 insertions(+), 52 deletions(-) > >> 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: MUKESH RATHOR <mukeshrathor@microsoft.com> Sent: Monday, November 11, 2024 10:53 AM > > On 11/10/24 20:12, Michael Kelley wrote: > > From: Nuno Das Neves <nunodasneves@linux.microsoft.com> Sent: > Thursday, November 7, 2024 2:32 PM > >> > >> To support Hyper-V Dom0 (aka Linux as root partition), many new > >> definitions are required. > > > > Using "dom0" terminology here and in the Subject: line is likely to > > be confusing to folks who aren't intimately involved in Hyper-V work. > > Previous Linux kernel commit messages and code for running in the > > Hyper-V root partition use "root partition" terminology, and I couldn't > > find "dom0" having been used before. "root partition" would be more > > consistent, and it also matches the public documentation for Hyper-V. > > "dom0" is Xen specific terminology, and having it show up in Hyper-V > > patches would be confusing for the casual reader. I know "dom0" has > > been used internally at Microsoft as shorthand for "Hyper-V root > > partition", but it's probably best to completely avoid such shorthand > > in public Linux kernel patches and code. > > > > Just my $.02 .... > > Hi Michael, > > FWIW, hyperv team and us are using the term "dom0" more and more to > avoid confusion between windows root and linux root, as dom0 is > always linux root. I did a quick search, and "dom0" is neither > copyrighted nor trademarked by xen, and I'm sure the fine folks > there won't be offended. Hopefully, [Hyper-V] tag would reduce > the confusion. > > Just my $0.1 > Yeah, "dom0" certainly fits as shorthand for the rather ponderous "Linux running in a Hyper-V root partition". :-) But even using "Hyper-V dom0" to add clarity vs. Xen dom0 seems to me to be a misnomer because Hyper-V dom0 is only conceptually like Xen dom0. It's not actually an implementation of Xen dom0. Let me give two examples: 1) Hyper-V provides VMBus, which is conceptually similar to virtio. But VMBus is not an implementation of virtio, and we don't call it "Hyper-V virtio". Of course, "VMBus" is a lot shorter than "Hyper-V root partition" so the motivation for a shorthand isn't there, but still. If Hyper-V should ever implement actual virtio interfaces, then it would be valid to call that "Hyper-V virtio". 2) KVM has "KVM Hyper-V", which I think is valid. It's an implementation of Hyper-V interfaces in KVM so that Windows guests can run as if they are running on Hyper-V. I won't speculate on what the Xen folks would think of "Hyper-V dom0", especially if it isn't an implementation that's compatible with Xen dom0 functionality. As for "more and more" usage of "dom0" by your team and the Hyper-V team: Is that internal usage only? Or usage in public mailing lists or open source projects like Cloud Hypervisor? Again, from my standpoint, internal is internal and can be whatever is convenient and properly understood internally. But in public mailing lists and projects, I think "Hyper-V dom0" should be avoided unless it's truly an implementation of the dom0 interfaces. That's probably now $0.10 worth instead of $0.02. :-) And I'm not the decider here -- I'm just offering a perspective. Michael
On 11/11/24 13:28, Michael Kelley wrote: > From: MUKESH RATHOR <mukeshrathor@microsoft.com> Sent: Monday, November 11, 2024 10:53 AM >> >> On 11/10/24 20:12, Michael Kelley wrote: >> > From: Nuno Das Neves <nunodasneves@linux.microsoft.com> Sent: >> Thursday, November 7, 2024 2:32 PM >> >> >> >> To support Hyper-V Dom0 (aka Linux as root partition), many new >> >> definitions are required. >> > >> > Using "dom0" terminology here and in the Subject: line is likely to >> > be confusing to folks who aren't intimately involved in Hyper-V work. >> > Previous Linux kernel commit messages and code for running in the >> > Hyper-V root partition use "root partition" terminology, and I couldn't >> > find "dom0" having been used before. "root partition" would be more >> > consistent, and it also matches the public documentation for Hyper-V. >> > "dom0" is Xen specific terminology, and having it show up in Hyper-V >> > patches would be confusing for the casual reader. I know "dom0" has >> > been used internally at Microsoft as shorthand for "Hyper-V root >> > partition", but it's probably best to completely avoid such shorthand >> > in public Linux kernel patches and code. >> > >> > Just my $.02 .... >> >> Hi Michael, >> >> FWIW, hyperv team and us are using the term "dom0" more and more to >> avoid confusion between windows root and linux root, as dom0 is >> always linux root. I did a quick search, and "dom0" is neither >> copyrighted nor trademarked by xen, and I'm sure the fine folks >> there won't be offended. Hopefully, [Hyper-V] tag would reduce >> the confusion. >> >> Just my $0.1 >> > > Yeah, "dom0" certainly fits as shorthand for the rather ponderous > "Linux running in a Hyper-V root partition". :-) > > But even using "Hyper-V dom0" to add clarity vs. Xen dom0 seems > to me to be a misnomer because Hyper-V dom0 is only conceptually > like Xen dom0. It's not actually an implementation of Xen dom0. > Let me give two examples: > > 1) Hyper-V provides VMBus, which is conceptually similar to virtio. > But VMBus is not an implementation of virtio, and we don't call it > "Hyper-V virtio". Of course, "VMBus" is a lot shorter than "Hyper-V > root partition" so the motivation for a shorthand isn't there, but still. > If Hyper-V should ever implement actual virtio interfaces, then it > would be valid to call that "Hyper-V virtio". > > 2) KVM has "KVM Hyper-V", which I think is valid. It's an > implementation of Hyper-V interfaces in KVM so that Windows > guests can run as if they are running on Hyper-V. > > I won't speculate on what the Xen folks would think of "Hyper-V > dom0", especially if it isn't an implementation that's compatible > with Xen dom0 functionality. > > As for "more and more" usage of "dom0" by your team and the > Hyper-V team: Is that internal usage only? Or usage in public mailing > lists or open source projects like Cloud Hypervisor? Again, from > my standpoint, internal is internal and can be whatever is convenient > and properly understood internally. But in public mailing lists and > projects, I think "Hyper-V dom0" should be avoided unless it's > truly an implementation of the dom0 interfaces. > > That's probably now $0.10 worth instead of $0.02. :-) And I'm > not the decider here -- I'm just offering a perspective. "dom0" is neither a technology nor a protocol. It simply means initial domain (which on xen happened to be domid of 0, could have been 1). This is created during boot, same as linux root on hyperv, and is privileged domain same as xen. Even in KVM world, I've heard many folks refer to the host as kvm dom0... Given the mix of windows and linux with l1vh and nested, dom0 is helping in conversations internally, and I'm sure it will keep percolating externally. Thanks, -Mukesh
From: MUKESH RATHOR <mukeshrathor@microsoft.com> Sent: Monday, November 11, 2024 3:11 PM > > On 11/11/24 13:28, Michael Kelley wrote: > > From: MUKESH RATHOR <mukeshrathor@microsoft.com> Sent: Monday, November 11, 2024 10:53 AM > >> > >> On 11/10/24 20:12, Michael Kelley wrote: > >> > From: Nuno Das Neves <nunodasneves@linux.microsoft.com> Sent: > >> Thursday, November 7, 2024 2:32 PM > >> >> > >> >> To support Hyper-V Dom0 (aka Linux as root partition), many new > >> >> definitions are required. > >> > > >> > Using "dom0" terminology here and in the Subject: line is likely to > >> > be confusing to folks who aren't intimately involved in Hyper-V work. > >> > Previous Linux kernel commit messages and code for running in the > >> > Hyper-V root partition use "root partition" terminology, and I couldn't > >> > find "dom0" having been used before. "root partition" would be more > >> > consistent, and it also matches the public documentation for Hyper-V. > >> > "dom0" is Xen specific terminology, and having it show up in Hyper-V > >> > patches would be confusing for the casual reader. I know "dom0" has > >> > been used internally at Microsoft as shorthand for "Hyper-V root > >> > partition", but it's probably best to completely avoid such shorthand > >> > in public Linux kernel patches and code. > >> > > >> > Just my $.02 .... > >> > >> Hi Michael, > >> > >> FWIW, hyperv team and us are using the term "dom0" more and more to > >> avoid confusion between windows root and linux root, as dom0 is > >> always linux root. I did a quick search, and "dom0" is neither > >> copyrighted nor trademarked by xen, and I'm sure the fine folks > >> there won't be offended. Hopefully, [Hyper-V] tag would reduce > >> the confusion. > >> > >> Just my $0.1 > >> > > > > Yeah, "dom0" certainly fits as shorthand for the rather ponderous > > "Linux running in a Hyper-V root partition". :-) > > > > But even using "Hyper-V dom0" to add clarity vs. Xen dom0 seems > > to me to be a misnomer because Hyper-V dom0 is only conceptually > > like Xen dom0. It's not actually an implementation of Xen dom0. > > Let me give two examples: > > > > 1) Hyper-V provides VMBus, which is conceptually similar to virtio. > > But VMBus is not an implementation of virtio, and we don't call it > > "Hyper-V virtio". Of course, "VMBus" is a lot shorter than "Hyper-V > > root partition" so the motivation for a shorthand isn't there, but still. > > If Hyper-V should ever implement actual virtio interfaces, then it > > would be valid to call that "Hyper-V virtio". > > > > 2) KVM has "KVM Hyper-V", which I think is valid. It's an > > implementation of Hyper-V interfaces in KVM so that Windows > > guests can run as if they are running on Hyper-V. > > > > I won't speculate on what the Xen folks would think of "Hyper-V > > dom0", especially if it isn't an implementation that's compatible > > with Xen dom0 functionality. > > > > As for "more and more" usage of "dom0" by your team and the > > Hyper-V team: Is that internal usage only? Or usage in public mailing > > lists or open source projects like Cloud Hypervisor? Again, from > > my standpoint, internal is internal and can be whatever is convenient > > and properly understood internally. But in public mailing lists and > > projects, I think "Hyper-V dom0" should be avoided unless it's > > truly an implementation of the dom0 interfaces. > > > > That's probably now $0.10 worth instead of $0.02. :-) And I'm > > not the decider here -- I'm just offering a perspective. > > "dom0" is neither a technology nor a protocol. It simply means initial > domain (which on xen happened to be domid of 0, could have been 1). This > is created during boot, same as linux root on hyperv, and is privileged > domain same as xen. Even in KVM world, I've heard many folks refer to > the host as kvm dom0... > > Given the mix of windows and linux with l1vh and nested, dom0 is helping > in conversations internally, and I'm sure it will keep percolating > externally. > OK, fair enough. My perspective is probably more limited than yours as my experience with "dom0" is exclusively with the Xen code in a Linux kernel environment. I just haven't seen "dom0" used elsewhere, but that certainly doesn't mean it's not being done. If the decision on the Microsoft side is that introducing "Hyper-V dom0" terminology makes sense, I won't object further, though I would think there should be some kind of reconciliation with existing code/comments/documentation that uses "root partition". Michael
To support Hyper-V Dom0 (aka Linux as root partition), many new definitions are required. The plan going forward is to directly import definitions from Hyper-V code without waiting for them to land in the TLFS document. This is a quicker and more maintainable way to import definitions, and is a step toward the eventual goal of exporting headers directly from Hyper-V for use in Linux. This patch series introduces new headers (hvhdk.h, hvgdk.h, etc, see patch #3) derived directly from Hyper-V code. hyperv-tlfs.h is replaced with hvhdk.h (which includes the other new headers) everywhere. No functional change is expected. Summary: Patch 1-2: Minor cleanup patches Patch 3: Add the new headers (hvhdk.h, etc..) in include/hyperv/ Patch 4: Switch to the new headers Signed-off-by: Nuno Das Neves <nunodasneves@linux.microsoft.com> --- Changelog: v2: - Rework the series to simply use the new headers everywhere instead of fiddling around to keep hyperv-tlfs.h used in some places, suggested by Michael Kelley and Easwar Hariharan - Fix compilation errors with some configs by adding missing definitions and changing some names, thanks to Simon Horman for catching those - Add additional definitions to the new headers to support them now replacing hyperv-tlfs.h everywhere - Add additional context in the commit messages for patches #3 and #4 - In patch #2, don't remove indirect includes. Only remove includes which truly aren't used, suggested by Michael Kelley --- Nuno Das Neves (4): hyperv: Move hv_connection_id to hyperv-tlfs.h hyperv: Clean up unnecessary #includes hyperv: Add new Hyper-V headers in include/hyperv hyperv: Switch from hyperv-tlfs.h to hyperv/hvhdk.h arch/arm64/hyperv/hv_core.c | 3 +- arch/arm64/hyperv/mshyperv.c | 4 +- arch/arm64/include/asm/mshyperv.h | 2 +- arch/x86/hyperv/hv_apic.c | 1 - arch/x86/hyperv/hv_init.c | 21 +- arch/x86/hyperv/hv_proc.c | 3 +- arch/x86/hyperv/ivm.c | 1 - arch/x86/hyperv/mmu.c | 1 - arch/x86/hyperv/nested.c | 2 +- arch/x86/include/asm/kvm_host.h | 3 +- arch/x86/include/asm/mshyperv.h | 3 +- arch/x86/include/asm/svm.h | 2 +- arch/x86/kernel/cpu/mshyperv.c | 2 +- arch/x86/kvm/vmx/hyperv_evmcs.h | 2 +- arch/x86/kvm/vmx/vmx_onhyperv.h | 2 +- arch/x86/mm/pat/set_memory.c | 2 - drivers/clocksource/hyperv_timer.c | 2 +- drivers/hv/hv_balloon.c | 4 +- drivers/hv/hv_common.c | 2 +- drivers/hv/hv_kvp.c | 2 +- drivers/hv/hv_snapshot.c | 2 +- drivers/hv/hyperv_vmbus.h | 2 +- include/asm-generic/hyperv-tlfs.h | 9 + include/asm-generic/mshyperv.h | 2 +- include/clocksource/hyperv_timer.h | 2 +- include/hyperv/hvgdk.h | 303 +++++++ include/hyperv/hvgdk_ext.h | 46 + include/hyperv/hvgdk_mini.h | 1295 ++++++++++++++++++++++++++++ include/hyperv/hvhdk.h | 733 ++++++++++++++++ include/hyperv/hvhdk_mini.h | 310 +++++++ include/linux/hyperv.h | 11 +- net/vmw_vsock/hyperv_transport.c | 2 +- 32 files changed, 2729 insertions(+), 52 deletions(-) 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