When using a multi-threaded CPU, is it possible to treat a thread as a core to have double the available cores to the guest OS?
Assuming you mean 'thread' in the same sense as a thread of execution provided by technologies such as Intel's HyperThreading, or the SMT implementations on AMD Ryzen (or Sun/Oracle/whoever UltraSPARC, or any number of other platforms), then yes, but probably not for the reasons you might think.
At a low level, the 'threads' on a given core have some form of shared resources, although exactly what they share depends on the implementation (almost all share cache, but beyond that it's kind of hit or miss). However, as far as user applications are concerned, they're no different from individual cores (some platforms differentiate physical CPU's (packages times cores-per-package) from logical CPU's (threads-per-core times cores-per-package times packages), but realistically, user programs almost never treat them any differently).
In the case of QEMU, this is actually entirely decoupled from what it exposes to the guest system. By default, it provides exactly one core, and exposes nothing about the host system's hardware topology. With the use of the
-smp option to provide arbitrary topologies. With just a number, it simulates a single CPU with that many cores, but for many platforms, you can specify exact values for the number of cores per package, number of threads per core, and number of sockets to expose. So, in theory you could expose the 8 cores with 2 TPC (threads-per-core) of a Ryzen 7 to a QEMU guest as 16 independent cores, or a single core with 16 threads, or even as 16 separate CPU packages with 1 core each. You can even give the guest more virtual cores than there are physical cores on the system, in which case those core swill be multiplexed across however many physical CPU's you have (this is really useful for testing purposes).