Ü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-/Modulkandidatvmw_vsock_virtio_transport— Kernel-Treiber-/Modulkandidat
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.
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 BDFBDF 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*/driverBDF 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_transportDiese 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.
Quellen
Eine Quellenprüfung hält geprüfte Implementierung oder Dokumentation fest, keinen reproduzierten Hardwaretest. Versionsbezogene Tabellen belegen weder Mindestkernel noch garantierte Funktion.
- Linux: drivers/virtio/virtio_pci_common.c
Geprüfter Upstream-Quellcode
virtio_pci_id_table[] - Linux: drivers/virtio/virtio_pci_modern_dev.c
Geprüfter Upstream-Quellcode
mdev->id.device = pci_dev->device - 0x1040; - Linux: include/uapi/linux/virtio_ids.h
Geprüfter Upstream-Quellcode
#define VIRTIO_ID_VSOCK - Linux: net/vmw_vsock/virtio_transport.c
Geprüfter Upstream-Quellcode
{ VIRTIO_ID_VSOCK, - Linux: Documentation/driver-api/virtio/virtio.rst
Projekt- oder Distributionsdokumentation
Device discovery and probing - Linux: net/vmw_vsock/Makefile
Geprüfter Upstream-Quellcode
vmw_vsock_virtio_transport-y