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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/11/24 13:28, Michael Kelley wrote:
 > From: MUKESH RATHOR <mukeshrathor@xxxxxxxxxxxxx> Sent: Monday, 
November 11, 2024 10:53 AM
 >>
 >> On 11/10/24 20:12, Michael Kelley wrote:
 >>   > From: Nuno Das Neves <nunodasneves@xxxxxxxxxxxxxxxxxxx> 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






[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux