From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52387) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTmju-0007qJ-Ap for qemu-devel@nongnu.org; Thu, 11 Feb 2016 03:36:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTmjr-00058t-51 for qemu-devel@nongnu.org; Thu, 11 Feb 2016 03:36:38 -0500 Received: from e06smtp17.uk.ibm.com ([195.75.94.113]:47628) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTmjq-00058o-RD for qemu-devel@nongnu.org; Thu, 11 Feb 2016 03:36:35 -0500 Received: from localhost by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 11 Feb 2016 08:36:32 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 15968219005F for ; Thu, 11 Feb 2016 08:36:15 +0000 (GMT) Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u1B8aTmP11010124 for ; Thu, 11 Feb 2016 08:36:29 GMT Received: from d06av02.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u1B8aSuu023851 for ; Thu, 11 Feb 2016 01:36:28 -0700 Date: Thu, 11 Feb 2016 09:36:27 +0100 From: David Hildenbrand Message-ID: <20160211093627.2e294e8c@thinkpad-w530> In-Reply-To: <56BB651A.5080306@suse.de> References: <1453913621-20961-1-git-send-email-mjrosato@linux.vnet.ibm.com> <20160210162843.3315d423@thinkpad-w530> <56BB651A.5080306@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 00/10] Allow hotplug of s390 CPUs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andreas =?UTF-8?B?RsOkcmJlcg==?= , cornelia.huck@de.ibm.com, imammedo@redhat.com Cc: Matthew Rosato , qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com, bharata@linux.vnet.ibm.com, pbonzini@redhat.com, rth@twiddle.net > Am 10.02.2016 um 16:28 schrieb David Hildenbrand: > > For x86, cpu models are realized by making x86_64-cpu an abstract class and > > creating loads of new classes, e.g. host-x86_64-cpu or haswell-x86_64-cpu. > > > > How does 'device_add ' play together with the x86 cpu model > > approach? And with cpu models specified via "-cpu" in general? > > device_add needs to use an instantiatable type, like the ones you sketch > above. > > > Or does that in return mean, that "making models own classes" is outdated? Or > > will some internal conversion happen that I am missing? > > > > What is the plan for cpu models and cpu hotplug? How are cpu models to be > > defined in the future? > > Someone at IBM was working on defining models for s390x - not sure what > the status is? That one is me right now :) Michael Mueller was working on a version without explicit features last year. I'm now looking into models with features that can be turned on/off - like x86 has. As I'm trying to get a view of the bigger picture I also have to take care of cpu hotplug, and I am not quite sure yet if we (s390) really want or need a device_add. a) Specification of cpu model and cpu hotplug on QEMU start -smp 2,maxcpus=6 -cpu zBC12,+feata,+featb,prop=value Here, it is quite clear that all cpus will get the same feature set. We don't need any information about internals (e.g. which class is used internally for the cpu) b) Adding cpus via the monitor "cpu_add" cpu-add id=3 Quite easy, we get what we ordered when starting QEMU, a cpu just like the others. c) Adding a cpu via device_add device_add s390-cpu,id=3 -> Not uniform. We _want_ cpu models as cpu subclasses (http://wiki.qemu.org/Features/CPUHotplug) OR device_add zBC12-s390-cpu,id=3 -> Not uniform. We don't specify the properties. But we have to specify some magic class that we didn't have to specify on the command line. Implicitly used information for a device. OR device_add zBC12-s390-cpu,id=3,feata=on,featb=off,prop=value -> Fully specified. Again. And we need information about the internally used class. Implicitly used information for a device. Especially the last two examples are bad: 1) We could hotplug _different_ cpus, which is absolutely not what we want on s390. 2) In every sane setup, we have to respecify what we already setup up at QEMU start. (and I don't see any benefit) 3) Interface that is much more complex and more error prone to use. d) Benefits of the new interface. Unfortunately I can't seem to find any (http://wiki.qemu.org/Features/CPUHotplug) but what I can think of 1) Specify something like topology more detailed (IMHO not applicable for s390) 2) Do a device_del (IMHO not applicable for s390) Both of these points could easily be realized by extending the existing cpu-add and by introducing a cpu_del (if really needed). I am not against this, I just want to understand what the plan is. Because this highly overcomplicates matter for us (s390) and requires yet another interface to be maintained (I have some quote about new interfaces in the back of my hand from some Linus guy ;) ) "Targets are encouraged to (re)design CPU creation so that it would be possible to use device_add/device-del interface for it. However if due to target design or a necessary long re-factoring time to use CPU with device_add/device-del interface, it is possible speed-up CPU hot-add feature development by using cpu-add interface." (http://wiki.qemu.org/Features/CPUHotplug) If nobody can convince me that this is the way to go and everything I said is already clear or wrong, then I'd vote for keeping it simple and using cpu-add. David