Wie aktiviere ich die AVX- und AVX2-Befehlssätze in einer Gast-VM?

Hallo Comunity,

Ich habe einen Ubuntu Server 24.04.4 LTS unter VirtualBox Version 7.2.8 r173730 (Qt6.8.0 on windows) in einer VM installiert.

Mein Host Betriebssystem: Windows 11 Pro; Version: 25H2; Build: 26200.8655; Windows Feature Experience Pack 1000.26100.315.0

Host Hardware: CPU: i9-13900KF @ 5 GHz; GPU: Nvidia RTX 4090 OC; RAM: 64 GB DDR @6000; 3 mal NVMe je 2 TB; 3 mal SATA SSD je 4 TB

Gast Hardware: Prozessoren: 8; Hauptspeicher: 8192 MB; Grafikspeicher: 256 MB; Grafikcontroller: VMSVGA; 3D-Beshleunigung: aktiviert

Folgendes habe ich schon versucht:

BIOS bzw. UEFI

Secure Boot => Deaktiviert
Secure Core => Deaktiviert

Windows

Einstellungen → Datenschutz und Sicherheit → Windows-Sicherheit → Gerätesicherheit → Kernisolierung → Details zur Kernisolierung

Speicher-Integrität => AUS geschaltet => anschließend Computer neu gestartet

Folgende Befehle alle in einer Administrator CMD (Eingabeaufforderung) eingegeben und ausgeführt.

Hypervisor start disable => bcdedit /set hypervisorlaunchtype off
Microsoft Hyper-V disable => DISM /Online /Disable-Feature:Microsoft-Hyper-V
Optional: bcdedit /set xsavedisable 1

anschließend neu start

VBoxManage.exe modifyvm "guest_name" --paravirtprovider none --hwvirtex off --nested-hw-virt off
VBoxManage.exe setextradata "guest_name" VBoxInternal/CPUM/IsaExts/AVX 1
VBoxManage.exe setextradata "guest_name" VBoxInternal/CPUM/IsaExts/AVX2 1

anschließend neu start

Windows Features überprüft

Systemsteuerung → Programme und Features → Windows-Features aktivieren oder deaktivieren

Container: AUS
Plattform für virtuelle Computer: AUS
Windows Projected File System: AUS
Sperrmodus für Geräte: AUS
Überwachter Host: AUS
Windows-Hypervisor Platform: AUS
Windows-Sandbox: AUS
Windows-Subsystem für Linux: AUS

anschließend neu start

VirtualBox gestartet
Den virtuellen Ubuntu Server gestartet
eingeloggt

USER@COMPUTERNAME:~$ cat /proc/cpuinfo | grep flags | sort -u
flags           : fpu ... avx avx2 …
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 cx16 pcid sse4_1 sse4_2 movbe popcnt aes rdrand hypervisor lahf_lm abm 3dnowprefetch ibrs_enhanced fsgsbase bmi1 bmi2 invpcid rdseed adx clflushopt sha_ni arat md_clear flush_l1d arch_capabilities

VBox.log Überprüft:

…
00:00:04.962081   AVX - AVX support                                       = 0
…

VBoxManage.exe modifyvm "guest_name" --nested-hw-virt on löste das Problem auch nicht.

Gefühlt habe ich schon jeden Tipp aus dem Internet umgesetzt.

Wie aktiviere ich die AVX- und AVX2-Befehlssätze in der Gast-VM?

Grüße aus dem Ruhrgebiet
Andreas

Zwei Dinge fallen mir auf: --hwvirtex off würde ich wieder rückgängig machen, weil AVX in einer VM normalerweise gerade an Hardware-Virtualisierung/CPU-Passthrough hängt. Außerdem ist bcdedit /set xsavedisable 1 verdächtig, denn AVX braucht XSAVE/OSXSAVE-Unterstützung. Also erst diese beiden Änderungen zurücknehmen, Windows komplett neu starten und dann im Gast mit lscpu oder grep -m1 „flags“ /proc/cpuinfo prüfen. Wenn VBox.log weiter AVX support = 0 zeigt, ist es eher ein VirtualBox/Host-Konfigurationsproblem als etwas im Ubuntu-Gast.

Entschuldige die späte Rückmeldung. Deinen Hinweis habe ich umgesetzt. Hat das Problem leider nicht gelöst.

Habe dann gestern den ganzen Tag noch andere Konfigurationen getestet.

Egal was ich versucht habe, VBox.log zeigte immer AVX support = 0.

So das ich frustriert auf meinem zweiten, etwa 10 Jahre altem Computer mit Windows 10 Pro,
VirtualBox installiert, und anschließend eine Ubuntu Server VM installiert habe. Nichts von dem, was ich in meinem ersten Post geschrieben habe, umgesetzt.

VBox.log zeigt hier direkt AVX support = 1, ohne irgendwelche Änderungen an Einstellungen oder Konfigurationen.

So das es mit an Sicherheit grenzender Wahrscheinlichkeit kein Ubuntu-Gast oder VirtualBox/Host-Konfigurationsproblem sein kann. Sondern eher ein Windows 11 Problem.

Wer kann schon sagen was Microsoft hier wieder verschlimmbessert hat.

Hintergrund

Ich wollte LM Studio, bzw. llmster unter Linux in einer VM Testen.

Dabei stellte sich heraus, daß es zu Fehlermeldungen bei der Installation kommt.

Der Grund dafür ist das die AVX- und AVX2-Befehlssätze der Host-CPU nicht an die GAST-CPU durchgereicht werden.

Bin mal gespannt wie Microsoft sich äußert: Die AVX- und AVX2-Befehlssätze meiner CPU, werden nicht an die VM durchgereicht - Microsoft Q&A

Wenn VBox.log auf dem Windows-11-Rechner immer `AVX support = 0` zeigt, würde ich noch einmal außerhalb von VirtualBox prüfen, ob Windows wirklich keine VBS-Schicht mehr dazwischen hat: `msinfo32` öffnen und bei „Virtualisierungsbasierte Sicherheit“ nachsehen. Wenn dort noch „Wird ausgeführt“ steht, sind oft Credential Guard/Device Guard oder Reste der Windows-Hypervisor-Plattform aktiv, auch wenn Hyper-V in den Features abgewählt ist. Außerdem würde ich `bcdedit /deletevalue xsavedisable` setzen (oder sicher `xsavedisable 0`) und testweise VirtualBox 7.1.x gegen 7.2.x vergleichen. Der Ubuntu-Gast ist hier ziemlich sicher nur der Bote der schlechten Nachricht.

Auf meinen aktuellem Rechner hatte ich vor dem (Zwangs)-Upgrade auf Windows 11 auch Windows 10 installiert. Und es hat darunter Fehler- und Problemlos funktioniert.

Hyper-V habe ich komplett deinstalliert:

xsavedisable habe ich nur optional eingesetzt. Hatte vor der Installation von llmster in der VM einen Snapshot der VM erstellt. Und bin nach jeder Änderung von Konfigurationen und/oder Einstellungen wieder zu diesem Snapshot zurück, bevor ich llmster erneut installiert habe.

Auch bcdedit /set xsavedisable 0 habe ich schon versucht.

Ich habe alle möglichen Konfigurationen und Einstellungen, getestet. Natürlich immer mit einem Neu-Start des Betriebssystem nach der Änderung.

Auf meinem alten Rechner mit Windows 10 ist die selbe Version von VirtualBox installiert wie auf meinem neuen Computer mit Windows 11.

Credential Guard/Device Guard hatte ich testweise, natürlich nach vorherigem Backup und trennen der Internet Verbindung, auch deaktiviert. Nichts hat das Problem gelöst.

Auch im BIOS bzw. UEFI habe ich schon alles Versucht:

Das BIOS bzw. UEFI ist das aktuellste, welches für mein Motherboard erhältlich ist. Da ich regelmäßig auf der Support-Seite des Herstellers nach sehe. Und sobald dort eine neuere Version erscheint, ich auf diese update.

So das für mich logischer weise nur ein Schuldiger übrig bleibt: Windows 11!

Mikrosoft bietet keine Möglichkeit auf der Support-Seite einen neuen Fall auf zu machen. Jedenfalls konnte ich keine finden.

Nach Feedback-Hub Meldung bekomme ich den Hinweis, dieses doch als Bug zu melden.

Ja nee, ist schon klar! Ich soll also 72 Euro dafür zahlen, damit ich einen, nach Ihrer Meinung – einen Ihnen schon, durch die Feedback-Hub Meldung von mir – bekannten Bug noch einmal melden darf.

Das ist meiner Meinung, mit freundlichen Worten ausgedrückt, für einen Konzern der Milliarden Gewinne macht, einfach nur armselig.

Und zeigt das Endkunde Microsoft total egal ist, und überhaupt nicht interessiert.

Sie Interessiert es nicht das Du:

  • Seit 1992 mit Windows 3.1 bzw. Windows 3.11 angefangen, und mit geholfen hast das Unternehmen zu dem zu machen, was es heute ist.
  • Du seit Existenz des Feedback-Hub tausende von Rückmeldungen, Vorschläge und Fehler darüber gemeldet hast.

Nein sie Interessieren sich nur für dein „Bestes“, dein Geld. Der Rest geht dehnen am … vorbei.

Allein die Tatsache das die Updates, die Windows 10 LTSC IOT bis 2035 erhält, nicht an die anderen Windows 10 Versionen weitergegeben werden.

Zeigt meiner Meinung nach, wie viel der Endbenutzer Microsoft bedeutet.

Nachtrag zur Information

VBS (Virtualisierungsbasierte Sicherheit) habe wie folgt abgeschaltet:

1. Credential Guard über Registrierungseinstellungen deaktivieren
       Key path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
       Key name: LsaCfgFlags
       Type: REG_DWORD
       Value: 0


       Key path: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard
       Key name: LsaCfgFlags
       Type: REG_DWORD
       Value: 0

2. Deaktivieren von Credential Guard mit UEFI-Sperre über die Administrator Windows-Eingabeaufforderung   
       mountvol X: /s
       copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
       bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
       bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
       bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
       bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO
       bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
       mountvol X: /d

3. Deaktivieren der VBS über die Registrierungseinstellungen. Löschen der folgenden Registrierungsschlüssel:
       Key path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
       Key name: EnableVirtualizationBasedSecurity

       Key path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
       Key name: RequirePlatformSecurityFeatures

4. Über die Administrator Windows-Eingabeaufforderung
       bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS
       bcdedit /set vsmlaunchtype off

5. Im Group policies editor 

Computerconfiguration -> Admininistrative Vorlagen -> System -> Device Guard -> Virtualsierungsbasierte Sicherheit aktivieren => Auf deaktiviert gestellt.

6. Deaktivieren aller Optionen unter „Kernisolierung“ in Windows 11
Windows Einstellungen -> Datenschutz und Sicherheit -> Geräte Sicherheit -> Kernisolierung -> Details zu Kernisolierung 
	Speicher-Integrität = AUS
	Hardware-gestützter Stapelschutz im Kernel Kernel-Modus = Ist AUS da für diese Funktion Speicher-Integrität aktiviert sein muss

7. Systemsteuerung -> Programme und Features -> Windows Futures aktivieren oder deaktivieren -> Abgewählt: Hyper-V, Windows-Subsystem für Linux

8. Computer Neu Start
Neustart. Bevor das Betriebssystem hochfährt, erscheint eine Meldung, die darauf hinweist, dass UEFI geändert wurde, und um Bestätigung bittet. (Drücken von F3 und anschließend die Eingabetaste, um fortzufahren.)