All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: KVM devel mailing list <kvm@vger.kernel.org>,
	qemu-devel <qemu-devel@nongu.org>
Subject: KVM call minutes for 2016-02-16
Date: Tue, 16 Feb 2016 18:28:06 +0100	[thread overview]
Message-ID: <8737ss7eft.fsf@emacs.mitica> (raw)


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.



                 reply	other threads:[~2016-02-16 17:28 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=8737ss7eft.fsf@emacs.mitica \
    --to=quintela@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.