
Un framework Linux permettant de définir des shims de cartes PCIe "virtuelles" définis par l'espace utilisateur pour faciliter le développement de pilotes de cartes PCIe dans l'hôte.
PCIem est un framework qui crée des périphériques PCIe virtuels dans le noyau Linux en exploitant quelques techniques novatrices pour peupler des cartes synthétiques en tant que périphériques PCI légitimes pour l'OS hôte.
Pour résumer ce qu'est PCIem : un framework pour (bien que non limité à) développer et tester des pilotes de périphériques PCIe sans nécessiter de matériel réel sur l'hôte.
PCIem et libfvio-user sont deux solutions différentes pour des besoins différents, il peut y avoir une confusion lors de la comparaison des deux, voici donc les différences (Voir figure 1 pour plus de détails).
La principale est que libvfio-user repose généralement sur un client (qui implémente le protocole vfio-user), généralement QEMU (via KVM, en utilisant des sorties de VM) pour exposer le périphérique PCIe émulé à l'invité. Vous écrivez votre serveur (avec un mécanisme de rappel généralement) qui interagit ensuite avec le client.
vfioCe que fait PCIem à la place, c'est exposer le périphérique directement sur l'hôte ; pas de KVM, pas d'invités, pas de machines virtuelles, rien. Le périphérique apparaît sur le bus PCIe de l'hôte comme s'il était physiquement connecté.
| Fonctionnalité | PCIem | libfvio-user |
|---|---|---|
| Connexion | Fichier de périphérique (/dev/pciem) | Sockets UNIX (protocole vfio-user) |
| Pilote cible s'exécute sur | Hôte | OS invité |
| Périphérique émulé s'exécute sur | Espace utilisateur | Espace utilisateur |
| Accès au périphérique | Direct (sur l'hôte) | Virtualisé (invité vers hôte) |
Figure 1 : Comparaison entre les frameworks
graph LR
subgraph Kernel ["Host Linux Kernel"]
direction TB
RealDriver["Real PCIe Driver"]
subgraph Framework ["PCIem Framework"]
direction TB
Config["PCI Config Space"]
BARs["BARs"]
IRQ["Interrupts"]
DMA["DMA / IOMMU"]
end
end
Interface(("/dev/pciem"))
subgraph User ["Linux Userspace"]
direction TB
Shim["Device Emulation"]
end
Framework <==> Interface
Interface <==> Shim
6.6gcc-12amd64/i386, aarch64, riscvNote aarch64 : Testé avec Raspberry Pi 4b, device-tree (pas d'ACPI)
Note riscv : Testé avec VisionFive 2 (Device-tree) et Muse Pi Pro (Device-tree et ACPI)
| Distribution | |||
|---|---|---|---|
| Ubuntu Dernière | - | - | |
| Ubuntu 24.04 LTS | |||
| Debian Stable |
Une carte compatible Bochs BGA (bochs-drm) qui peut être pilotée par des utilitaires espace utilisateur tels que Weston ; utilise SDL3.
Contrôleur NVME avec 1 Go de stockage attaché. L'utilisateur peut librement formater, monter, créer et supprimer des fichiers depuis la mémoire.
Modèle d'émulation compatible ICH6 capable de jouer des échantillons en conjonction avec pipewire.
NOTE : Légers craquements audio uniquement entendus sur l'enregistrement, fonctionne parfaitement autrement.
Une implémentation assez naïve de la carte E1000. Prend en charge la redirection des communications vers/depuis votre vraie carte réseau. Peut également utiliser le Wi-Fi mais c'est moins stable.
La carte est programmée entièrement dans QEMU (machine d'état pour la carte, en gros), qui effectue toute l'initialisation de l'espace utilisateur et la gestion des commandes à partir du vrai pilote s'exécutant sur l'hôte.
Peut exécuter DOOM rendu par logiciel (soumet les images terminées via DMA à la carte que QEMU affiche) et aussi des jeux simples OpenGL 1.X (sur les captures d'écran, tyr-glquake et xash3d ; grâce à une machine d'état OpenGL personnalisée implémentée entièrement dans QEMU qui rend les listes de commandes par logiciel et met à jour l'état interne en conséquence).
| - |
| - |
| Fedora Dernière | - | - |
| openSUSE Tumbleweed | - | - |