qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <dahi@linux.vnet.ibm.com>
To: "Andreas Färber" <afaerber@suse.de>,
	cornelia.huck@de.ibm.com, imammedo@redhat.com
Cc: Matthew Rosato <mjrosato@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com,
	bharata@linux.vnet.ibm.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH v3 00/10] Allow hotplug of s390 CPUs
Date: Thu, 11 Feb 2016 09:36:27 +0100	[thread overview]
Message-ID: <20160211093627.2e294e8c@thinkpad-w530> (raw)
In-Reply-To: <56BB651A.5080306@suse.de>

> 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 <cpu class>' 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

      reply	other threads:[~2016-02-11  8:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-27 16:53 [Qemu-devel] [PATCH v3 00/10] Allow hotplug of s390 CPUs Matthew Rosato
2016-01-27 16:53 ` [Qemu-devel] [PATCH v3 01/10] exec: Remove cpu from cpus list during cpu_exec_exit() Matthew Rosato
2016-01-27 16:53 ` [Qemu-devel] [PATCH v3 02/10] exec: Do vmstate unregistration from cpu_exec_exit() Matthew Rosato
2016-01-27 16:53 ` [Qemu-devel] [PATCH v3 03/10] cpu: Reclaim vCPU objects Matthew Rosato
2016-01-27 16:53 ` [Qemu-devel] [PATCH v3 04/10] cpu: Add a sync version of cpu_remove() Matthew Rosato
2016-01-27 16:53 ` [Qemu-devel] [PATCH v3 05/10] s390x/cpu: Cleanup init in preparation for hotplug Matthew Rosato
2016-01-27 16:53 ` [Qemu-devel] [PATCH v3 06/10] s390x/cpu: Set initial CPU state in common routine Matthew Rosato
2016-01-27 16:53 ` [Qemu-devel] [PATCH v3 07/10] s390x/cpu: Move some CPU initialization into realize Matthew Rosato
2016-01-30 12:01   ` David Hildenbrand
2016-01-27 16:53 ` [Qemu-devel] [PATCH v3 08/10] s390x/cpu: Add functions to (un)register CPU state Matthew Rosato
2016-01-27 16:53 ` [Qemu-devel] [PATCH v3 09/10] s390/virtio-ccw: Add hotplug handler and prepare for unplug Matthew Rosato
2016-01-27 16:53 ` [Qemu-devel] [PATCH v3 10/10] s390x/cpu: Allow hot plug/unplug of CPUs Matthew Rosato
2016-02-01  8:52 ` [Qemu-devel] [PATCH v3 00/10] Allow hotplug of s390 CPUs Christian Borntraeger
2016-02-10 15:28 ` David Hildenbrand
2016-02-10 16:28   ` Andreas Färber
2016-02-11  8:36     ` David Hildenbrand [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160211093627.2e294e8c@thinkpad-w530 \
    --to=dahi@linux.vnet.ibm.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=imammedo@redhat.com \
    --cc=mjrosato@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).