Assumindo que você quer dizer "thread" no mesmo sentido que um thread de execução fornecido por tecnologias como HyperThreading da Intel ou as implementações SMT no AMD Ryzen (ou Sun / Oracle / qualquer um dos UltraSPARC ou qualquer número de outras plataformas), então sim, mas provavelmente não pelas razões que você pensa.
Em um nível baixo, os 'threads' em um determinado núcleo têm alguma forma de recursos compartilhados, embora exatamente o que eles compartilhem depende da implementação (quase todo o cache de compartilhamento, mas além disso é um tipo de acerto ou erro). No entanto, no que diz respeito aos aplicativos de usuários, eles não são diferentes dos núcleos individuais (algumas plataformas diferenciam as CPUs físicas (pacotes vezes núcleos por pacote) das CPUs lógicas (vezes por núcleo, vezes núcleos por pacote, vezes pacotes). ), mas, realisticamente, os programas do usuário quase nunca os tratam de maneira diferente.
No caso do QEMU, isso é realmente totalmente dissociado do que é exposto ao sistema convidado. Por padrão, ele fornece exatamente um núcleo e não expõe nada sobre a topologia de hardware do sistema host. Com o uso da opção -smp para fornecer topologias arbitrárias. Com apenas um número, ele simula uma única CPU com muitos núcleos, mas, para muitas plataformas, é possível especificar valores exatos para o número de núcleos por pacote, o número de segmentos por núcleo e o número de soquetes a serem expostos. Então, em teoria, você poderia expor os 8 núcleos com 2 TPC (threads por núcleo) de um Ryzen 7 para um convidado do QEMU como 16 núcleos independentes, ou um único núcleo com 16 segmentos, ou até mesmo como 16 pacotes separados de CPU com 1 core cada. Você pode até dar ao convidado mais núcleos virtuais do que núcleos físicos no sistema, caso em que esses núcleos serão multiplexados através de quantas CPUs físicas você tiver (isso é realmente útil para propósitos de teste).