Angenommen, Sie meinen "Thread" im selben Sinne wie ein Thread der Ausführung, der von Technologien wie Intels HyperThreading oder den SMT-Implementierungen auf AMD Ryzen (oder Sun / Oracle / whoever UltraSPARC oder einer beliebigen Anzahl anderer Plattformen) bereitgestellt wird. aber wahrscheinlich nicht aus den Gründen, die Sie vielleicht denken.
Auf einer niedrigen Ebene verfügen die "Threads" eines bestimmten Kerns über eine Form gemeinsam genutzter Ressourcen. Die von ihnen gemeinsam genutzten Ressourcen hängen jedoch von der Implementierung ab (fast alle teilen sich den Cache, aber darüber hinaus ist dies ein Treffer oder ein Fehlschlag). In Bezug auf Benutzeranwendungen unterscheiden sie sich jedoch nicht von einzelnen Kernen (einige Plattformen unterscheiden physikalische CPU (Pakete mal Cores pro Paket) von logischen CPU (Threads pro Kern mal Cores pro Paket mal Pakete) ), aber realistisch behandeln Benutzerprogramme sie fast nie anders.
Im Fall von QEMU ist dies tatsächlich vollständig von dem entkoppelt, was es dem Gastsystem zur Verfügung stellt. Standardmäßig stellt es genau einen Kern bereit und gibt keinerlei Informationen über die Hardwaretopologie des Hostsystems ab. Mit der Verwendung der-smpOption zur Bereitstellung beliebiger Topologien. Mit nur einer Zahl wird eine einzelne CPU mit so vielen Kernen simuliert. Bei vielen Plattformen können Sie jedoch genaue Werte für die Anzahl der Kerne pro Paket, die Anzahl der Threads pro Kern und die Anzahl der freizugebenden Sockets angeben. Theoretisch könnten Sie also die 8 Kerne mit 2 TPC (Threads pro Kern) einer Ryzen 7 einem QEMU-Gast als 16 unabhängige Kerne oder einen einzelnen Kern mit 16 Threads oder sogar als 16 separate CPU-Pakete mit 1 aussetzen Kern jeweils. Sie können dem Gast sogar mehr virtuelle Kerne zuweisen, als physische Kerne im System vorhanden sind. In diesem Fall werden diese Kerne über mehrere beliebige physische CPUs hinweg gemultiplext (dies ist sehr nützlich für Testzwecke).