Hi Ramdom ideas that I took for the talk, I hope that some of the active participants can reply with a more coherent viewe. State of the art (Andreas) - Having very specific socket objects - Dynamic allocation using new parameters - Which level should we be doing the hotplug (granularuty) x86-> socket level powerpc -> core z390 -> thread level Christin - Low level device adding - Initialize from the beggining all cpu objects Hot-plugging would be to put them on-line - how cpu came into being - how are we going to add in x86 with device add * x86 and sparc -cpu handling is special case * not copy that on s390, better example in ARM? - Way to handle this? * save the feature string internally, for reusing with new cpu * how best handle, it can depend of cpu model and board * how to make libvirt level not crazy? * should we hide the cpu add inside the machine implementation * having an array of empty sockets where to plug new cpus * only compatible types can be set on link property (not sure how well are enforced) * set the link property of the machine to the core object just created * powerpc cpu object is realized hook should check that it is done is a hot plug operation to automate this * powerpc only has cores and threads * we can have a property in the core object to know where it goes * if each core has two threads, when we add a new core, we always add 2 threads * cpu_add have a type={core,thread,whatever} what is the problem with it? * pre-created id's for cpu_add? * do different implementations and then try to find commonalities. * ARM can need to be able to add different cpu models * how to specify the topology * cpu_add has always thought to be an interim solution until we get the real one * problems with migration, spcially with cpu_del * get cpu_add on x86 * they don't support unplug * they don't support topology * realization matters about where we put the things, in child or parent object Later, JUan. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html