From: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
To: bharata@linux.vnet.ibm.com
Cc: Zhu Guihua <zhugh.fnst@cn.fujitsu.com>,
cornelia.huck@de.ibm.com, qemu-devel@nongnu.org, agraf@suse.de,
borntraeger@de.ibm.com, Chen Fan <chen.fan.fnst@cn.fujitsu.com>,
Gu Zheng <guz.fnst@cn.fujitsu.com>,
pbonzini@redhat.com, afaerber@suse.de, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH v2 1/9] cpus: Reclaim vCPU objects
Date: Fri, 20 Nov 2015 08:37:40 -0500 [thread overview]
Message-ID: <564F2224.6060103@linux.vnet.ibm.com> (raw)
In-Reply-To: <20151120023324.GA32166@in.ibm.com>
On 11/19/2015 09:33 PM, Bharata B Rao wrote:
> On Thu, Nov 19, 2015 at 10:10:06AM -0500, Matthew Rosato wrote:
>> From: Gu Zheng <guz.fnst@cn.fujitsu.com>
>>
>> In order to deal well with the kvm vcpus (which can not be removed without any
>> protection), we do not close KVM vcpu fd, just record and mark it as stopped
>> into a list, so that we can reuse it for the appending cpu hot-add request if
>> possible. It is also the approach that kvm guys suggested:
>> https://www.mail-archive.com/kvm@vger.kernel.org/msg102839.html
>>
>> Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
>> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
>> Signed-off-by: Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
>> Signed-off-by: Bharata B Rao <bharata@linux.vnet.ibm.com>
>> [Explicit CPU_REMOVE() from qemu_kvm/tcg_destroy_vcpu()
>> isn't needed as it is done from cpu_exec_exit()]
>
> I didn't look very closely but the patch that removes cpu from the list
> from cpu_exec_exit() isn't part of this series. The above change requires
>
> https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg00656.html
>
> I have just cleaned that patch a bit and will be posting early next
> week with another patch that does CPU vmstate unregistration too from
> cpu_exec_exit(). I think since we do vmstate registration from cpu_exec_init()
> it makes sense to do unregistration from cpu_exec_exit() instead of
> archs doing it themselves. I had a version of this at
>
> https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg00649.html
>
> With the above patch, you woudn't need 7/9 in this series.
>
Hi Bharata -- Looking at the mailing list discussion from your patch
set, I got the impression that handling this in cpu_exec_exit() might
not be acceptable for all architectures. So, my patch just tries to
handle the s390 case in patch 7/9, doing list removal and vmstate
unregistration.
FWIW, the 2 patches you referenced would be fine for s390, so if you can
get those approved I'd have no problem dropping 7/9 in favor of your
patches.
Matt
next prev parent reply other threads:[~2015-11-20 13:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-19 15:10 [Qemu-devel] [PATCH v2 0/9] s390: Allow hotplug of s390 CPUs Matthew Rosato
2015-11-19 15:10 ` [Qemu-devel] [PATCH v2 1/9] cpus: Reclaim vCPU objects Matthew Rosato
2015-11-20 2:33 ` Bharata B Rao
2015-11-20 13:37 ` Matthew Rosato [this message]
2015-11-19 15:10 ` [Qemu-devel] [PATCH v2 2/9] cpus: Add a sync version of cpu_remove() Matthew Rosato
2015-11-19 15:25 ` Paolo Bonzini
2015-11-19 15:36 ` Matthew Rosato
2015-11-19 15:10 ` [Qemu-devel] [PATCH v2 3/9] s390x/cpu: Cleanup init in preparation for hotplug Matthew Rosato
2015-11-19 15:10 ` [Qemu-devel] [PATCH v2 4/9] s390x/cpu: Set initial CPU state in common routine Matthew Rosato
2015-11-19 15:10 ` [Qemu-devel] [PATCH v2 5/9] s390x/cpu: Move some CPU initialization into realize Matthew Rosato
2015-11-19 15:10 ` [Qemu-devel] [PATCH v2 6/9] s390x/cpu: Add functions to (un)register CPU state Matthew Rosato
2015-11-19 15:10 ` [Qemu-devel] [PATCH v2 7/9] s390x/cpu: Extra cleanup during CPU finalize Matthew Rosato
2015-11-19 15:10 ` [Qemu-devel] [PATCH v2 8/9] s390/virtio-ccw: Add hotplug handler and prepare for unplug Matthew Rosato
2015-11-19 15:10 ` [Qemu-devel] [PATCH v2 9/9] s390x/cpu: Allow hot plug/unplug of CPUs Matthew Rosato
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=564F2224.6060103@linux.vnet.ibm.com \
--to=mjrosato@linux.vnet.ibm.com \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=bharata@linux.vnet.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=chen.fan.fnst@cn.fujitsu.com \
--cc=cornelia.huck@de.ibm.com \
--cc=guz.fnst@cn.fujitsu.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=zhugh.fnst@cn.fujitsu.com \
/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.