From: Alexander Graf <agraf@suse.de>
To: Christian Borntraeger <borntraeger@de.ibm.com>,
KVM <kvm@vger.kernel.org>, qemu-devel <qemu-devel@nongnu.org>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Jens Freimann <jfrei@linux.vnet.ibm.com>,
David Hildenbrand <dahi@linux.vnet.ibm.com>,
linux-s390 <linux-s390@vger.kernel.org>
Subject: Re: [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work"
Date: Mon, 28 Jul 2014 15:49:06 +0200 [thread overview]
Message-ID: <53D654D2.40308@suse.de> (raw)
In-Reply-To: <1404997839-29038-5-git-send-email-borntraeger@de.ibm.com>
On 10.07.14 15:10, Christian Borntraeger wrote:
> From: David Hildenbrand <dahi@linux.vnet.ibm.com>
>
> If a cpu is stopped, it must never be allowed to run and no interrupt may wake it
> up. A cpu also has to be unhalted if it is halted and has work to do - this
> scenario wasn't hit in kvm case yet, as only "disabled wait" is processed within
> QEMU.
>
> Signed-off-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
> Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
This looks like it's something that generic infrastructure should take
care of, no? How does this work for the other archs? They always get an
interrupt on the transition between !has_work -> has_work. Why don't we
get one for s390x?
Alex
next prev parent reply other threads:[~2014-07-28 13:49 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-10 13:10 [Qemu-devel] [PATCH/RFC 0/5] s390x/kvm: track the logical cpu state in QEMU and propagate it to kvm Christian Borntraeger
2014-07-10 13:10 ` [Qemu-devel] [PATCH/RFC 1/5] update linux headers with with cpustate changes Christian Borntraeger
2014-07-10 13:10 ` [Qemu-devel] [PATCH/RFC 2/5] s390x/kvm: introduce proper states for s390 cpus Christian Borntraeger
2014-07-10 13:10 ` [Qemu-devel] [PATCH/RFC 3/5] s390x/kvm: proper use of the cpu states OPERATING and STOPPED Christian Borntraeger
2014-07-10 13:10 ` [Qemu-devel] [PATCH/RFC 4/5] s390x/kvm: test whether a cpu is STOPPED when checking "has_work" Christian Borntraeger
2014-07-28 13:49 ` Alexander Graf [this message]
2014-07-28 14:16 ` David Hildenbrand
2014-07-28 14:19 ` Paolo Bonzini
2014-07-28 14:22 ` Alexander Graf
2014-07-28 15:03 ` David Hildenbrand
2014-07-28 15:57 ` David Hildenbrand
2014-07-28 16:45 ` Alexander Graf
2014-07-29 13:52 ` Paolo Bonzini
2014-07-29 15:06 ` David Hildenbrand
2014-07-29 11:44 ` Christian Borntraeger
2014-07-29 11:49 ` Alexander Graf
2014-07-31 7:45 ` David Hildenbrand
2014-07-10 13:10 ` [Qemu-devel] [PATCH/RFC 5/5] s390x/kvm: propagate s390 cpu state to kvm Christian Borntraeger
2014-07-10 13:14 ` [Qemu-devel] [PATCH/RFC 0/5] s390x/kvm: track the logical cpu state in QEMU and propagate it " David Hildenbrand
2014-07-10 13:14 ` David Hildenbrand
2014-07-10 13:27 ` David Hildenbrand
2014-07-28 13:43 ` Alexander Graf
2014-07-28 13:45 ` Alexander Graf
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=53D654D2.40308@suse.de \
--to=agraf@suse.de \
--cc=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=dahi@linux.vnet.ibm.com \
--cc=jfrei@linux.vnet.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.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 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).