[EXTERNAL] RE: [PATCH v2 0/4] Add new headers for Hyper-V Dom0

Michael Kelley mhklinux at outlook.com
Mon Nov 11 13:28:28 PST 2024


From: MUKESH RATHOR <mukeshrathor at microsoft.com> Sent: Monday, November 11, 2024 10:53 AM
> 
> On 11/10/24 20:12, Michael Kelley wrote:
>  > From: Nuno Das Neves <nunodasneves at 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


More information about the linux-arm-kernel mailing list