Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Es gibt einige Einschränkungen beim passthrough, die auch vom Chipsatz abhängig sein können.
An IOMMU group is the smallest set of physical devices that can be passed to a virtual machine. For instance, in the example above, both the GPU in 06:00.0 and its audio controller in 6:00.1 belong to IOMMU group 13 and can only be passed together. The frontal USB controller, however, has its own group (group 2) which is separate from both the USB expansion controller (group 10) and the rear USB controller (group 4), meaning that any of them could be passed to a virtual machine without affecting the others. https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF#Ensuring_that_the_groups_are_valid
Jetzt stellt sich mir die Frage - wäre ein NVME-Slot auf dem Board in der lspci-Ausgabe sichtbar - auch wenn KEINE SSD drin steckt? (hab grad kein alternatives Gerät im Zugriff, um das selbst zu checken)
Hab das Internet natürlich nach weiteren Infos zum Gerät abgegrast (und sogat ein Hardware Maintenance Manual gefunden) - aber sicher ist nur, dass NVME-SSDs funktionieren (in der Bios-Boot-Reihenfolge gibt es sogar ein Item NVME01) - aber keine Info zur Anbindung - und auch keine Performance-Vergleiche zw. SATA- und NVME-SSDs (aus denen man evtl Rückschlüsse ziehen könnte).
Uridium schrieb:
Es gibt einige Einschränkungen beim passthrough ...
Ohjee ... hatte nicht erwartet, dass man sooo weit in die Tiefe gehen muss. Ich kneif mir das erstmal , und setze die VM auf "klassische" Art auf.
Aber inzwischen würde ich glatt aus Neugier eine NVME-SSD kaufen und schauen, was passiert. Der Chipsatz unterstützt max. PCIe 3.0, und 500GB sind für meine Zwecke mehr als genug ... gibt es da eine Empfehlung, oder kann ich dafür "Irgendwas" kaufen?
Jetzt stellt sich mir die Frage - wäre ein NVME-Slot auf dem Board in der lspci-Ausgabe sichtbar - auch wenn KEINE SSD drin steckt? (hab grad kein alternatives Gerät im Zugriff, um das selbst zu checken)
Hänge die Ausgabe mal als Textdatei an. Ich hab darin keine Hinweise auf einen M.2 Slot gefunden, dafür eine Menge OEM-spezifischen nicht decodierten Kram.
Weiss aber auch nicht, wie es "richtig" auszusehen hat, ob der Hersteller das überhaupt richtig eingetragen hat ... Kann einer der Linux-User mit NVME-SSD bitte mal die Ausgabe von
"sudo dmidecode -t slot"
posten?
So ... hatte heute die Gelegenheit, mir eine NVMe-SSD aus einem Arbeitsrechner auszuleihen und in den Laptop zu stecken - die auch prompt in der Ausgabe von lspci erscheint - direkt an einem PCIe-Port - und ohne Umweg über den SATA-Controller.
Die NVMe-SSD ist ca 2,5x schneller beim Lesen, was aber eher an den verbauten Chips liegt, und nicht in der Anbindung, die auch bei SATA bei Weitem nicht ausgelastet ist.
Wenn es jemanden interessiert, poste ich heute abend vergleichende Ausgaben von lspci, hdparm, dd, usw.
Ok - verglichen wird, im SELBEN M2-Slot - eine SATA-SSD (SanDisk SD8SN8U128G1001), eingebunden als /dev/sdb - mit einer PCIe 4.0 NVME-SSD (Lexar NM790), eingebunden als /dev/nvme0n1.
Das System läuft währenddessen von einer temporär als /dev/sda eingestöpselten 2,5" HD.
lsblk stellt das folgendermassen dar
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 298,1G 0 disk ├─sda1 8:1 0 37,3G 0 part / ├─sda2 8:2 0 3,7G 0 part [SWAP] └─sda3 8:3 0 257,1G 0 part /home sdb 8:16 0 119,2G 0 disk ├─sdb1 8:17 0 44,7G 0 part ├─sdb2 8:18 0 67,1G 0 part └─sdb3 8:19 0 7,5G 0 part sr0 11:0 1 1024M 0 rom
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 298,1G 0 disk ├─sda1 8:1 0 37,3G 0 part / ├─sda2 8:2 0 3,7G 0 part [SWAP] └─sda3 8:3 0 257,1G 0 part /home sr0 11:0 1 1024M 0 rom nvme0n1 259:0 0 953,9G 0 disk ├─nvme0n1p1 259:1 0 100M 0 part ├─nvme0n1p2 259:2 0 16M 0 part ├─nvme0n1p3 259:3 0 953,2G 0 part └─nvme0n1p4 259:4 0 562M 0 part
Die NVME-SSD wird durch diesen Eintrag repräsentiert 03:00.0 Non-Volatile memory controller: Shenzhen Longsys Electronics Co., Ltd. Device 1602 (rev 01)
der bei eingesteckter SATA-SSD nicht existiert. Sonst keine Unterschiede.
Von Interesse sind hier die Einträge: LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us LnkSta: Speed 8GT/s (downgraded), Width x2 (downgraded)
--> eine PCIe-4.0-SSD steckt in einem PCIe-3.0-Slot, und ist offenbar nur mit 2 Lanes angebunden.
Zum Schluss noch ein einfacher Performance-Tests., SATA-SSD: # hdparm -Tt /dev/sdb dev/sdb: Timing cached reads: 17102 MB in 1.99 seconds = 8600.35 MB/sec Timing buffered disk reads: 1526 MB in 3.00 seconds = 508.09 MB/sec
Der erste Wert repräsentiert das Lesen aus dem Cache und zeigt im Wesentlichen die Grenzen von CPU und RAM, der zweite sequentielles Lesen von der Platte, ohne Dateisystemoverhead.
Dito für die NVME-SSD: # hdparm -Tt /dev/nvme0n1 /dev/nvme0n1: Timing cached reads: 17664 MB in 1.99 seconds = 8884.39 MB/sec Timing buffered disk reads: 3890 MB in 3.00 seconds = 1296.54 MB/sec
Auffällig ist, dass die SATA-SSD das Interface (max. 600MB/s brutto) fast auslastet - während die NVME-SSD das nicht in dem Maße tut (max. 2000MB/s bei PCIE-3.0x2) - obwohl sie selbst 7400MB/s liefern soll, und das in zeitgemässen Systemen aucht tut 🤔
Auffällig ist, dass die SATA-SSD das Interface (max. 600MB/s brutto) fast auslastet - während die NVME-SSD das nicht in dem Maße tut (max. 2000MB/s bei PCIE-3.0x2) - obwohl sie selbst 7400MB/s liefern soll, und das in zeitgemässen Systemen aucht tut 🤔
Auffällig ist, dass die SATA-SSD das Interface (max. 600MB/s brutto) fast auslastet - während die NVME-SSD das nicht in dem Maße tut (max. 2000MB/s bei PCIE-3.0x2
2000 Mbyte netto mit PCIe 3x2 ist etwas zu optimistisch. In der Realität sind eher um 1500 Mbyte möglich. Die von Dir gemessenen 1296 sind da schon halbwegs im Rahmen.