Pourquoi les VM sur Apple Silicon sont-elles si différentes ?

Pourquoi les VM sur Apple Silicon sont-elles différentes ?

• Exécuter des machines virtuelles macOS (VM) sur des Mac Apple Silicon peut sembler peu populaire, mais cela fait depuis longtemps partie des objectifs importants d’Apple.
• Si l’on utilise un logiciel de virtualisation sur un Mac de série M, on constate à quel point cela diffère de la virtualisation de macOS et d’autres systèmes d’exploitation sur les Mac Intel.
• L’article explique pourquoi la virtualisation est importante et comment elle est devenue si différente.

Les trois piliers d’Apple Silicon

• Lors de la WWDC de juin 2020, Craig Federighi a présenté les trois piliers d’Apple Silicon : les applications universelles fonctionnant sur les deux architectures, Rosetta 2 qui traduit le code Intel en instructions Arm, et la virtualisation.
• Avant même qu’Apple ne lance le Developer Transition Kit, Andreas Wendker avait déjà fait une démonstration d’une version préliminaire de Parallels Desktop faisant tourner Linux comme invité, mais sans mention de Windows.

Les débuts de la virtualisation

• Au début de la virtualisation, on distinguait les hyperviseurs de type 1, qui s’exécutent directement sur le matériel, et ceux de type 2 (hébergés), où le système d’exploitation principal tourne sur le matériel et l’hyperviseur s’exécute au-dessus.
• Sur les ordinateurs de bureau, les produits de virtualisation de type 2 comme VMware Fusion, Parallels Desktop et Oracle VirtualBox sont plus courants.

Support matériel et virtualisation

• Lorsqu’un support matériel pour l’hyperviseur existe, il est plus facile d’exécuter des systèmes d’exploitation invités non modifiés.
• On peut utiliser l’ensemble de fonctions VT-x d’Intel ou la virtualisation AArch64 des CPU Arm.
• Les problèmes de prise en charge des périphériques peuvent être résolus dans le framework de virtualisation ou pris en charge par le logiciel de virtualisation.

La singularité des puces Apple Silicon

• Tous les périphériques matériels des puces Apple Silicon sont différents de leurs équivalents sur les Mac Intel.
• Même si Apple avait voulu tout documenter complètement pour un usage externe, l’effort d’ingénierie nécessaire pour la prise en charge des périphériques des Mac Intel aurait été trop coûteux pour des tiers.
• Il n’était donc pas réaliste de partir d’un hyperviseur en espérant construire un logiciel de virtualisation complet, et il aurait aussi été difficile d’atteindre les hautes performances attendues par Apple et ses utilisateurs.

Les pilotes Virtio et la virtualisation

• Apple a donc choisi d’intégrer dans macOS la prise en charge des périphériques via des pilotes Virtio.
• Virtio est un standard qui fournit une couche d’abstraction pour les périphériques d’E/S : lorsqu’un système d’exploitation invité tente d’ouvrir un fichier, la requête est transmise à un pilote para-virtualisé de stockage frontend Virtio, qui interagit ensuite avec le périphérique de stockage via un pilote backend Virtio.
• Créer une application de virtualisation consiste à configurer et ouvrir les périphériques Virtio nécessaires, puis à laisser l’invité, Virtio et l’hôte traiter le travail.

Le choix de Virtio par Apple

• Le choix d’Apple en faveur de Virtio a été influencé par le fait que Linux disposait déjà d’un bon support de Virtio, alors que macOS n’en avait pas à l’époque.
• Les ingénieurs d’Apple ont construit ce support de Virtio dans macOS pendant plusieurs années avant la sortie de Monterey.
• L’implémentation de Virtio dans macOS inclut des extensions prenant en charge le clavier et les périphériques de pointage, le presse-papiers partagé (« Spice »), ainsi que des graphismes hautes performances via la prise en charge de Metal et du GPU.

Les avantages du modèle Virtio

• Dans le modèle Virtio, c’est le système d’exploitation qui fournit la prise en charge, ce qui réduit les coûts de développement pour des éditeurs comme VMware et Parallels, tout en diminuant la valeur commerciale de leurs produits.
• Apple décide quels matériels et quelles fonctionnalités sont pris en charge par la virtualisation sur Apple Silicon.

L’avenir de la virtualisation et sa flexibilité

• Exécuter d’anciennes versions de macOS dans une VM permettra aux utilisateurs de continuer à lancer des applications uniquement Intel même après l’arrêt de la prise en charge de Rosetta 2 dans la version actuelle de macOS.
• Il sera aussi possible d’exécuter sur un Mac Apple Silicon des logiciels incompatibles avec la version minimale de macOS requise.
• Avec Linux ou macOS, les développeurs peuvent déployer des packages de VM légères comme Docker.

L’avis de GN⁺

• La virtualisation sur les Mac Apple Silicon adopte une approche différente de la virtualisation traditionnelle sur Intel, ce qui semble s’inscrire dans la stratégie d’Apple visant à renforcer l’intégration entre matériel et logiciel.
• La virtualisation via Virtio offre aux développeurs une solution économiquement efficace et permet une optimisation des performances sous le contrôle d’Apple.
• Les progrès des technologies de virtualisation ouvrent à long terme la possibilité d’offrir aux utilisateurs de Mac Apple Silicon des environnements logiciels variés, particulièrement utiles pour prendre en charge d’anciennes applications et d’anciens systèmes.

[molla]

La partie sur l’avenir de la virtualisation semble un peu étrange.
Le simple fait que la virtualisation soit possible ne signifie pas automatiquement qu’elle peut assurer la compatibilité avec les systèmes existants. À un moment ou à un autre, il faut bien convertir les instructions x86 en instructions ARM.
Si cela n’est pas pris en charge par le matériel ou l’OS (Rosetta ?), il ne reste alors qu’à l’émuler au niveau de la VM, mais dans ce cas la baisse de performances est très importante.
Même aujourd’hui, on peut installer un Linux x86 sur un Mac Apple Silicon, mais les performances sont incroyablement lentes. (L’an dernier, je crois, j’avais besoin d’un binaire x86, donc j’avais essayé d’en installer un pour compiler, avant d’abandonner presque immédiatement.)

[GN⁺]

Avis Hacker News

• Windows dépend de nombreuses fonctionnalités reposant sur Hyper-V, et lorsqu’elles sont activées, Windows ne démarre pas directement : Hyper-V se lance d’abord et le système Windows principal s’exécute dans une VM privilégiée.
• Quelqu’un cherche des informations sur l’état actuel de la virtualisation de Windows/Linux x86-64 sur Apple Silicon et regrette que l’article ne mentionne pas certaines applications importantes à ce sujet.
• Quelqu’un souhaite que tous les utilisateurs d’OS se connectent à la VM isolée de leur OS, afin qu’ils puissent ainsi conserver la pleine propriété de leur ordinateur Apple.
• Comme macOS ne peut exécuter que deux VM en même temps, si vous comptez utiliser un Mac mini comme serveur de build, il vaut mieux acheter le modèle le moins cher.
• Quelqu’un voulait utiliser Parallels pour le développement avec une VM macOS, mais ne pouvait pas se connecter avec un identifiant Apple, ce qui limite son utilisation.
• Quelqu’un se dit perplexe sur le fait que Docker fonctionne rapidement, avec des performances presque natives, sur la plateforme Linux/amd64, alors qu’une VM x86 sous UTM est bien plus lente.
• Une question est posée sur l’avancement de la couche virtio pour Windows, sur les personnes qui la développent, et sur la possibilité qu’elle fonctionne dans un avenir proche.
• Il est fait mention de pilotes écrits par Rusty Russell ; comme il partage des analyses très pertinentes sur le développement logiciel, il est recommandé de le suivre sur Twitter.
• Quelqu’un se demande si toutes les VM de bureau commerciales (VMWare Fusion/Parallels/UTM/Vimy) utilisent désormais le modèle virtio, et si, en théorie, Windows ARM64 devrait fonctionner à peu près de la même manière partout.
• Quelqu’un essaie depuis environ un an de trouver une commande unique pour créer une VM Qemu sur une puce Apple Silicon M2, mais rencontre des difficultés, alors qu’exécuter Alpine Linux + Sway WM dans Qemu sur macOS ou AsahiLinux est relativement simple en x86-64.