On Thu, May 02, 2019 at 05:09:28PM +0200, Igor Mammedov wrote: > On Tue, 30 Apr 2019 15:30:31 +0800 > Like Xu <like...@linux.intel.com> wrote: > > > On 2019/4/4 22:25, Igor Mammedov wrote: > > > On Fri, 29 Mar 2019 16:48:38 +0800 > > > Like Xu <like...@linux.intel.com> wrote: > > > > > [...] > > > > > The division of responsibility for this case (refactoring > > qemu_init_vcpu) seems to be a poisonous apple. > > > > The prerequisite for setting cpu-> nr_cores / nr_threads from the parent > > is that the CPU has been created, so if any process during > > initialization needs this topo information, it will use the default > > values form cpu_common_initfn() instead of user-configured parameters. > > can you point to concrete place that needs access to nr_cores / nr_threads > before cpu is 'realized'?
We have very few architectures actually using nr_cores/nr_threads/smp_cores/smp_threads. I think those variables are used only on x86, ppc, and mips. I believe I suggested some time ago that we should get rid of the nr_cores/nr_threads CPUState fields and move them to arch-specific types. This would help us avoid confusion when different architectures have different semantics for nr_cores/nr_threads. See https://www.mail-archive.com/qemu-devel@nongnu.org/msg587105.html ("[Qemu-devel] Meaning of '-smp threads' on mips_malta") for one example of confusing arch-specific semantics. -- Eduardo
