Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device

[Bharata B Rao]

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.