Hyper-V Paravirtualize

Discussions related to using VirtualBox on Windows hosts.
Post Reply
adamxx
Posts: 6
Joined: 8. Nov 2022, 03:47

Hyper-V Paravirtualize

Post by adamxx »

https://www.virtualbox.org/browser/vbox ... 84044#L366

Code: Select all

    
   /*
     * Don't report vendor as 'Microsoft Hv'[1] by default, see @bugref{7270#c152}.
     * [1]: ebx=0x7263694d ('rciM') ecx=0x666f736f ('foso') edx=0x76482074 ('vH t')
     */
From above code, HyperV is not reported to guest by default. Anyone know why not report by default when choose Hyper-V as paravirtualization interface? And I cannot find the @bugref{7270#c152}, anyone has the link?
fth0
Volunteer
Posts: 5668
Joined: 14. Feb 2019, 03:06
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...
Location: Germany

Re: Hyper-V Paravirtualize

Post by fth0 »

adamxx wrote:HyperV is not reported to guest by default
That sounds like you're misreading the VirtualBox source code:

By default, VirtualBox sets the Hyper-V Vendor ID to "VBoxVBoxVBox", puts that into the CPUID hypervisor leaves and provides the Hyper-V paravirtualization interface to the guest OS. If for any reason you need to pretend that the Hyper-V paravirtualization interface is provided by Windows instead of VirtualBox, you can use VBoxManage setextradata "VM Name" "VBoxInternal/GIM/HyperV/VendorID" "Microsoft Hv".
adamxx wrote:I cannot find the @bugref{7270#c152}, anyone has the link?
The VirtualBox source code references the internal bug tracker, which is not accessible to us mere VirtualBox users. ;)
scottgus1
Site Moderator
Posts: 20965
Joined: 30. Dec 2009, 20:14
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Windows, Linux

Re: Hyper-V Paravirtualize

Post by scottgus1 »

Another thing to possibly keep in mind, since you're considering Hyper-V in the context of Paravirtualization:

This Hyper-V Paravirtualization is not the host Windows Hyper-V that causes trouble for Virtualbox and is the cause of the green turtle Image .

'Paravirtualization Interface' is a comm channel for virtualization-aware OS's to talk to whatever hypervisor is running them, so they can run more efficiently. This comm channel needs a 'language' to use, defined only by the type of OS running in the VM. When running Windows VMs Virtualbox uses Hyper-V 'language' to talk to the Guest OS. When running Linux VMs, Virtualbox uses KVM 'language' to talk to the Guest OS. This is regardless of what type of host OS Virtualbox is running under.

So reporting Hyper-V by default on the paravirtualization channel would be wrong for Linux VMs, or whatever Mac & Solaris use.

All of the above may not be applicable, though, since fth0 knows the source code and I don't... :lol:
fth0
Volunteer
Posts: 5668
Joined: 14. Feb 2019, 03:06
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...
Location: Germany

Re: Hyper-V Paravirtualize

Post by fth0 »

scottgus1 wrote:'Paravirtualization Interface' is a comm channel for virtualization-aware OS's to talk to whatever hypervisor is running them, so they can run more efficiently. This comm channel needs a 'language' to use, defined only by the type of OS running in the VM. When running Windows VMs Virtualbox uses Hyper-V 'language' to talk to the Guest OS. When running Linux VMs, Virtualbox uses KVM 'language' to talk to the Guest OS. This is regardless of what type of host OS Virtualbox is running under.
Let me add one thing to connect that to the issue at hand:

On a communication channel, both ends better speak the same language. So what VirtualBox does, is to pretend to be a Hyper-V hypervisor in the case of a Windows guest and a KVM hypervisor in the case of a Linux guest, by providing some paravirtualization interfaces automatically supported by the guest OS.

I'll make an educated guess here what could be part of the reasoning in the internal bug ticket: If VirtualBox would not only provide expected paravirtualization interfaces, but also fake the Hyper-V Vendor ID, a Windows guest could expect all paravirtualization interfaces and their functionality that a real Hyper-V hypervisor provides.
adamxx
Posts: 6
Joined: 8. Nov 2022, 03:47

Re: Hyper-V Paravirtualize

Post by adamxx »

fth0 wrote:
adamxx wrote:HyperV is not reported to guest by default
That sounds like you're misreading the VirtualBox source code:

By default, VirtualBox sets the Hyper-V Vendor ID to "VBoxVBoxVBox", puts that into the CPUID hypervisor leaves and provides the Hyper-V paravirtualization interface to the guest OS. If for any reason you need to pretend that the Hyper-V paravirtualization interface is provided by Windows instead of VirtualBox, you can use VBoxManage setextradata "VM Name" "VBoxInternal/GIM/HyperV/VendorID" "Microsoft Hv".
The "setextradata" does not work. Below commands works:
VBoxManage modifyvm VM-name --paravirtdebug "enabled=1"
Ref: https://www.virtualbox.org/manual/ch09.html#gimdebug
adamxx
Posts: 6
Joined: 8. Nov 2022, 03:47

Re: Hyper-V Paravirtualize

Post by adamxx »

fth0 wrote:
scottgus1 wrote:'Paravirtualization Interface' is a comm channel for virtualization-aware OS's to talk to whatever hypervisor is running them, so they can run more efficiently. This comm channel needs a 'language' to use, defined only by the type of OS running in the VM. When running Windows VMs Virtualbox uses Hyper-V 'language' to talk to the Guest OS. When running Linux VMs, Virtualbox uses KVM 'language' to talk to the Guest OS. This is regardless of what type of host OS Virtualbox is running under.
Let me add one thing to connect that to the issue at hand:

On a communication channel, both ends better speak the same language. So what VirtualBox does, is to pretend to be a Hyper-V hypervisor in the case of a Windows guest and a KVM hypervisor in the case of a Linux guest, by providing some paravirtualization interfaces automatically supported by the guest OS.

I'll make an educated guess here what could be part of the reasoning in the internal bug ticket: If VirtualBox would not only provide expected paravirtualization interfaces, but also fake the Hyper-V Vendor ID, a Windows guest could expect all paravirtualization interfaces and their functionality that a real Hyper-V hypervisor provides.
My use case:
Host: Windows 11(HyperV on)
Guest: Linux(kernel 5.15)
VirualBox: 7.0.4 r154605 (Qt5.15.2)

I have tried to expose Hyper-V Vendor ID through "VBoxManage modifyvm VM-name --paravirtdebug "enabled=1"", then guest kernel could detect Hyper-V:
  • [ 0.000000] Hypervisor detected: Microsoft Hyper-V
    [ 0.000000] Hyper-V: privilege flags low 0xaf2, high 0x100800, hints 0x130, misc 0xd02
    [ 0.000000] Hyper-V Host Build:0-0.0-0-0.0
    [ 0.000000] Hyper-V: Nested features: 0x0
    [ 0.000000] Hyper-V: LAPIC Timer Frequency: 0x3d0900
    [ 0.000000] clocksource: hyperv_clocksource_tsc_page: mask: 0xffffffffffffffff max_cycles: 0x24e6a1710, max_idle_ns: 440795202120 ns
    [ 0.000002] tsc: Marking TSC unstable due to running on Hyper-V
    [ 0.325679] Booting paravirtualized kernel on Hyper-V
    [ 0.330402] Hyper-V: PV spinlocks disabled
    [ 0.616913] clocksource: Switched to clocksource hyperv_clocksource_tsc_page
And it seems Guest OS works fine.
So I am wondering why when I choose Hyper-V as paravirtualization interface in configuration, it is not reporting "Microsoft Hv" to guest. It requires me to use a specific command(--paravirtdebug) to do so. Is there any known issue? I am trying to figure out that in case of meet issue in future.
scottgus1
Site Moderator
Posts: 20965
Joined: 30. Dec 2009, 20:14
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Windows, Linux

Re: Hyper-V Paravirtualize

Post by scottgus1 »

adamxx wrote:Is there any known issue?
fth0 wrote:I'll make an educated guess here what could be part of the reasoning in the internal bug ticket: If VirtualBox would not only provide expected paravirtualization interfaces, but also fake the Hyper-V Vendor ID, a Windows guest could expect all paravirtualization interfaces and their functionality that a real Hyper-V hypervisor provides.
From what I gather from fth0's thoughts above:

Virtualbox provides some Hyper-V-language paravirtualization. So it uses a Virtualbox-based paravirtualization ID code to tell the Windows OS in the VM what to expect. Thus the Windows VM OS doesn't ask for what Virtualbox does not provide.

If Virtualbox provided a Microsoft-based paravirtualization ID code, the Windows VM OS would ask for the full gamut of paravirtualization, some of which Virtualbox may not have yet, and errors/slowdowns would ensue.

Just a guess, mind...
fth0
Volunteer
Posts: 5668
Joined: 14. Feb 2019, 03:06
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...
Location: Germany

Re: Hyper-V Paravirtualize

Post by fth0 »

adamxx wrote:The "setextradata" does not work.
You're right, and I didn't try it myself beforehand. While the command is syntactically correct and works (which can be verified in a VBox.log file), VirtualBox (6.1.40 in my case) apparently does not accept the resulting VM configuration as valid because of the missing Hyper-V debug interface that you found yourself. Kudos for that! :)

Your use case is somewhat special and beyond my current knowledge. Questions that come to mind:

When VirtualBox uses the underlying Windows hypervisor (Hyper-V, NEM), does it pass through the paravirtualization interface to the guest OS or does it still use its own implementation? If it's the latter, wouldn't it make more sense to provide the KVM paravirtualization interface instead, as if VirtualBox runs in VT-x mode? Why do you want to provide the Hyper-V paravirtualization interface?
klaus
Oracle Corporation
Posts: 1115
Joined: 10. May 2007, 14:57

Re: Hyper-V Paravirtualize

Post by klaus »

From our investigation Microsoft distinguishes between a 'Microsoft compatible' and a 'is Microsoft' hypervisor. We simply decided to play safe and not make a false claim.
adamxx
Posts: 6
Joined: 8. Nov 2022, 03:47

Re: Hyper-V Paravirtualize

Post by adamxx »

klaus wrote:From our investigation Microsoft distinguishes between a 'Microsoft compatible' and a 'is Microsoft' hypervisor. We simply decided to play safe and not make a false claim.
Thanks, understood. So there should no known issue if I use '--paravirtdebug "enabled=1"' to expose "Microsoft Hv" to guest, right?
fth0
Volunteer
Posts: 5668
Joined: 14. Feb 2019, 03:06
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Linux, Windows 10, ...
Location: Germany

Re: Hyper-V Paravirtualize

Post by fth0 »

fth0 wrote:When VirtualBox uses the underlying Windows hypervisor (Hyper-V, NEM), does it pass through the paravirtualization interface to the guest OS or does it still use its own implementation? If it's the latter, wouldn't it make more sense to provide the KVM paravirtualization interface instead, as if VirtualBox runs in VT-x mode? Why do you want to provide the Hyper-V paravirtualization interface?
Talking to myself: ;)

VirtualBox does not pass through the paravirtualization interface from the Windows hypervisor (Hyper-V), but provides its own, which by default is the one naturally matching the guest OS. So the question remains:

Why do you want to provide the Hyper-V paravirtualization interface instead of the KVM paravirtualization interface?

As klaus wrote, VirtualBox decided to play safe. When enabling the Hyper-V debug interface, VirtualBox is forced to provide "Microsoft Hv" as the Hyper-V Vendor ID to make it work. So if you provide this deliberately, you should rather "fear" unknown issues. ;)

As a general hint: The quality of our answers to your questions depend on the information that you give us ...
Post Reply