From: Luiz Capitulino <lcapitulino@redhat.com>
To: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
qemu-devel@nongnu.org, armbru@redhat.com, eblake@redhat.com,
berrange@redhat.com
Subject: Re: [Qemu-devel] [PATCH v2] qmp: add query-cpus-fast
Date: Fri, 9 Feb 2018 08:49:49 -0500 [thread overview]
Message-ID: <20180209084949.569007d7@redhat.com> (raw)
In-Reply-To: <f8157f02-4c16-6811-7857-e1ec4d55d49c@linux.vnet.ibm.com>
On Fri, 9 Feb 2018 08:56:19 +0100
Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> wrote:
> On 08.02.2018 21:33, Eduardo Habkost wrote:
> > On Thu, Feb 08, 2018 at 11:17:32AM -0500, Luiz Capitulino wrote:
> > [...]
> >> The "halted" field is somewhat controversial. On the one hand,
> >> it offers a convenient way to know if a guest CPU is idle or
> >> running. On the other hand, it's a field that can change many
> >> times a second. In fact, the halted state can change even
> >> before query-cpus-fast has returned. This makes one wonder if
> >> this field should be dropped all together. Having the "halted"
> >> field as optional gives a better option for dropping it in
> >> the future, since we can just stop returning it.
> >
> > I'd just drop it, unless we find a use case where it's really
> > useful.
I don't think there's any, unless for debugging purposes.
I'm keeping it mainly for s390. Viktor, libvirt is still using
this field in s390, no?
Dropping halted and having management software still using query-cpus
because of halted would be a total failure of query-cpus-fast.
> > Also, the code that sets/clears cpu->halted is target-specific,
> > so I wouldn't be so sure that simply checking for
> > !kvm_irqchip_in_kernel() is enough on all targets.
I checked the code and had the impression it was enough, but
I don't have experience with other archs. So, would be nice
if other archs maintainers could review this. I'll try to ping them.
> Right, the present patch effectively disables halted anyway (including
> s390).
No, it doesn't. It only disables halted for archs that require going
to the kernel to get it.
> So it may be cleaner to just drop it right now.
> Assuming the presence of architecure-specific data, libvirt can derive a
> halted state (or an equivalent thereof) from query-cpus-fast returned
> information.
This is a different proposal. You're proposing moving the halted state
to a CPU-specific field. This is doable if that's what we want.
next prev parent reply other threads:[~2018-02-09 13:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-08 16:17 [Qemu-devel] [PATCH v2] qmp: add query-cpus-fast Luiz Capitulino
2018-02-08 20:33 ` Eduardo Habkost
2018-02-09 7:56 ` Viktor Mihajlovski
2018-02-09 13:49 ` Luiz Capitulino [this message]
2018-02-09 14:16 ` Viktor Mihajlovski
2018-02-09 14:27 ` Eduardo Habkost
2018-02-09 14:50 ` Viktor Mihajlovski
2018-02-09 18:35 ` Luiz Capitulino
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=20180209084949.569007d7@redhat.com \
--to=lcapitulino@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=ehabkost@redhat.com \
--cc=mihajlov@linux.vnet.ibm.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).