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.