Virtuelle und ungewöhnliche Hardware

Virtio-Socket-Transport über modernes PCI

Virtuelle Sockets kommunizieren über Kontext-IDs statt über ein gewöhnliches Ethernet-Interface oder eine IP-Adresse.

Auf dieser Seite
  1. Überblick und Identität
  2. Treiber und Bindung
  3. Firmware
  4. Lesende Diagnose
  5. Grenzen und passende Fehlerhilfen
  6. Quellen

Überblick und Identität

Die geprüfte moderne PCI-Regel ordnet 1af4:1053 dem Virtio-Typ 19 (vsock) zu. Das ist eine virtuelle Funktionskennung, kein Hardwaremodell des Hosts. Transitionale PCI-IDs verwenden eine andere Subsystem-ID-Regel und werden hier bewusst nicht abgeleitet.

Kuratierte Kennungen
pci 1af4:1053

Ein numerischer Match belegt eine Kandidatenfamilie im geprüften Quellenrahmen. Verkaufsnamen, Platinenvarianten, Subsystembedingungen und erfolgreiche Funktion bleiben getrennte Fragen.

Treiber und Bindung

Die geprüfte Virtio-Vsock-Funktion passt auf Typ 19. Der Quelltext baut vmw_vsock_virtio_transport trotz seines von VMware abgeleiteten Namens; dieser Modulname belegt keinen VMware-Hypervisor, und Vsock ist nicht virtio_net. lspci kann daher korrekt virtio-pci melden, während die Kindfunktion an vmw_vsock_virtio_transport gebunden ist.

  • virtio_pci — Kernel-Treiber-/Modulkandidat
  • vmw_vsock_virtio_transport — Kernel-Treiber-/Modulkandidat

Erkannt, gebunden, funktionsfähig: Unterschiede verstehen

Firmware

Hier keine Host-Datei belegt

Im geprüften Treiberpfad wurde kein externer Firmware-Dateiname festgestellt. Das beschreibt nicht die im Gerät gespeicherte Firmware.

Firmwarepakete deiner Distribution prüfen

Lesende Diagnose

Führe jeden angezeigten Befehl einzeln aus. Ersetze Großbuchstaben-Platzhalter durch betroffenes Gerät, Schnittstelle oder Modul aus deiner Ausgabe. Hier wird nichts ausgeführt. Auch lesende Ausgaben können private Kennungen enthalten.

PCI-Funktion und Bindung prüfen

lspci -nnk -s BDF

BDF durch die vollständige Adresse ersetzen, etwa 0000:00:14.0. Diese lesende Abfrage benötigt pciutils und normalerweise kein sudo. „Kernel driver in use“ zeigt die beobachtete Bindung; „Kernel modules“ nennt Kandidaten.

Treiber der Virtio-Kindfunktion prüfen

ls -l /sys/bus/pci/devices/BDF/virtio*/driver

BDF durch die vollständige beobachtete PCI-Adresse ersetzen. Treiberlink des Kindgeräts ohne sudo lesen; virtio_pci ist der PCI-Transport, während dieser Link zum Funktionstreiber gehört. Fehlt Kindgerät oder Link, wurde diese Ebene nicht beobachtet.

Metadaten des installierten Vsock-Moduls prüfen

modinfo vmw_vsock_virtio_transport

Diese lesende kmod-Abfrage benötigt normalerweise kein sudo und lädt das Modul nicht. Metadaten belegen eine für den gewählten Kernel verfügbare Moduldatei; eingebaute Treiber oder fehlende Modulindizes können die Abfrage leer lassen, ohne eine fehlende Bindung zu beweisen.

Grenzen und passende Fehlerhilfen

Die Treiberregistrierung belegt weder einen lauschenden Hostdienst noch die gewünschte Kontext-ID oder Berechtigung. Keine Testnachrichten senden und ein fehlendes IP-Interface nicht als Ausfall dieses Transports ansehen.

Diese Anleitungen passen zu relevanten Befunden und behaupten keinen Fehler bei jedem Gerät dieser Familie.

Hardware-Diagnoseweg wählen · Log-Auszug im Fix Lab prüfen

Quellen

Eine Quellenprüfung hält geprüfte Implementierung oder Dokumentation fest, keinen reproduzierten Hardwaretest. Versionsbezogene Tabellen belegen weder Mindestkernel noch garantierte Funktion.