On Thu, Dec 10, 2015 at 03:25:53PM -0500, Matthew Rosato wrote: > On 12/10/2015 01:15 AM, Bharata B Rao wrote: > > Hi, > > > > This is an attempt to define a generic CPU device that serves as a > > containing device to underlying arch-specific CPU devices. The motivation > > for this is to have an arch-neutral way to specify CPUs mainly during > > hotplug. > > > > Instead of individual archs having their own semantics to specify the > > CPU like > > > > -device POWER8-powerpc64-cpu (pseries) > > -device qemu64-x86_64-cpu (pc) > > -device s390-cpu (s390) > > > > this patch introduces a new device named cpu-core that could be > > used for all target archs as > > > > -device cpu-core,socket="sid" > > > > This adds a CPU core with all its associated threads into the specified > > socket with id "sid". The number of target architecture specific CPU threads > > that get created during this operation is based on the CPU topology > > specified > > using -smp sockets=S,cores=C,threads=T option. Also the number of cores that > > can be accommodated in the same socket is dictated by the cores= parameter > > in the same -smp option. > > > > CPU sockets are represented by QOM objects and the number of sockets > > required > > to fit in max_cpus are created at boottime. As cpu-core devices are > > created, they are linked to socket object specified by socket="sid" device > > property. > > > > Thus the model consists of backend socket objects which can be considered > > as container of one or more cpu-core devices. Each cpu-core object is > > linked to the appropriate backend socket object. Each CPU thread device > > appears as child object of cpu-core device. > > > > All the required socket objects are created upfront and they can't be > > deleted. > > Though currently socket objects can be created using object_add monitor > > command, I am planning to prevent that so that a guest boots with the > > required number of sockets and only CPU cores can be hotplugged into > > them. > > > > CPU hotplug granularity > > ----------------------- > > CPU hotplug will now be done in cpu-core device granularity. > > > > This patchset includes a patch to prevent topologies that result in > > partially filled cores. Hence with this patchset, we will always > > have fully filled cpu-core devices both for boot time and during hotplug. > > > > For archs like PowerPC, where there is no requirement to be fully > > similar to the physical system, hotplugging CPU at core granularity > > is common. While core level hotplug will fit in naturally for such > > archs, for others which want socket level hotplug, could higher level > > tools like libvirt perform multiple core hotplugs in response to one > > socket hotplug request ? > > > > Are there archs that would need thread level CPU addition ? > > > > Boot time CPUs as cpu-core devices > > ---------------------------------- > > In this patchset, I am coverting the boot time CPU initialization > > (from -smp option) to initialize the required number of cpu-core > > devices and linking them with the appropriate socket objects. > > > > Initially I thought we should be able to completely replace -smp with > > -device cpu-core, but then I realized that at least both x86 and pseries > > guests' machine init code has dependencies on first CPU being available > > for the machine init code to work correctly. > > > > Currently I have converted boot CPUs to cpu-core devices only PowerPC sPAPR > > and i386 PC targets. I am not really sure about the i386 changes and the > > intention in this iteration was to check if it is indeed possible to > > fit i386 into cpu-core model. Having said that I am able to boot an x86 > > guest with this patchset. > > I attempted a quick conversion for s390 to using cpu-core, but looks > like we'd have an issue preventing s390 from using cpu-core immediately > -- it relies on cpu_generic_init, which s390 specifically avoids today > because we don't have support for cpu_models. Not sure if other > architectures will have the same issue.
I see that there are a few archs that don't have cpu_model, I guess we can teach cpu_generic_init() to handle that. I will attempt that in the next version if needed. Regards, Bharata.
