All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: Greg Kurz <groug@kaod.org>, qemu-devel@nongnu.org
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Thomas Huth <thuth@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	qemu-ppc@nongnu.org, David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] [PATCH] spapr: Explicitly check machine support before using EVENT_CLASS_HOT_PLUG
Date: Fri, 01 Mar 2019 10:20:16 -0600	[thread overview]
Message-ID: <155145721677.30057.3700488922747499209@sif> (raw)
In-Reply-To: <155144987334.126105.2493613675615671242.stgit@bahia.lan>

Quoting Greg Kurz (2019-03-01 08:17:53)
> Recent commit b8165118f52c "spapr: support memory unplug for qtest" broke
> CPU hotplug tests for old machine types:
> 
> $ QTEST_QEMU_BINARY=ppc64-softmmu/qemu-system-ppc64 ./tests/cpu-plug-test -m=slow
> /ppc64/cpu-plug/pseries-3.1/device-add/2x3x1&maxcpus=6: OK
> /ppc64/cpu-plug/pseries-2.12-sxxm/device-add/2x3x1&maxcpus=6: OK
> /ppc64/cpu-plug/pseries-3.0/device-add/2x3x1&maxcpus=6: OK
> /ppc64/cpu-plug/pseries-2.10/device-add/2x3x1&maxcpus=6: OK
> /ppc64/cpu-plug/pseries-2.11/device-add/2x3x1&maxcpus=6: OK
> /ppc64/cpu-plug/pseries-2.12/device-add/2x3x1&maxcpus=6: OK
> /ppc64/cpu-plug/pseries-2.9/device-add/2x3x1&maxcpus=6: OK
> /ppc64/cpu-plug/pseries-2.7/device-add/2x3x1&maxcpus=6: **
> ERROR:/home/thuth/devel/qemu/hw/ppc/spapr_events.c:313:rtas_event_log_to_source: assertion failed: (source->enabled)
> Broken pipe
> /home/thuth/devel/qemu/tests/libqtest.c:143: kill_qemu() detected QEMU death from signal 6 (Aborted) (core dumped)
> Aborted (core dumped)
> 
> The rtas_event_log_to_source() function is supposed to return the event
> source to be used for a given event type. In the case of hotplug, it first
> tries EVENT_CLASS_HOT_PLUG and, if the guest doesn't support it, it falls
> back to EVENT_CLASS_EPOW.
> 
> This works well for machine types that enable EVENT_CLASS_HOT_PLUG. For
> older machine types, this happened to work because they don't set the
> OV5_HP_EVT bit in spapr->ov5. CAS hence logically keeps the bit cleared
> in spapr->ov5_cas and we avoid the assert.
> 
> As shown by commit b8165118f52c, the logic is fragile and we need a
> bigger hammer to ensure that rtas_event_log_to_source() doesn't go
> down the EVENT_CLASS_HOT_PLUG path with older machine types.

I think that fact that we set spapr->ov5 based on relevant machine
options/support being there, and the fact that this means they won't
show up in ov5_cas, is a nice thing to assert and rely on, since being
able to rely on that keeps keeps the logic throughout the code tied to
ov5/ov5_cas and avoids the need to keep re-checking things like
spapr->use_hotplug_event_source (and various other options tied to an
OV5 capability) after init time.

I think this particular case is purely the result of us violating (via
b8165118f52c) the condition that bits that aren't ever set in spapr->ov5
should never end up in spapr->ov5_cas, and losing that precondition might
make the code harder to reason about since now we have to check both
ov5_cas and the related options (rather than 1 necessarilly following
from the other).

Another approach might be to revert b8165118f52c, and then add a hook for
qtest_enabled() that does a fake CAS negotiation (which I guess would
essentially involve copying spapr->ov5 into spapr->ov5_cas). This would
maintain the flow of machine options -> spapr->ov5 -> spapr->ov5_cas and
still let qtest do it's thing (AFAICT).

> 
> Signed-off-by: Greg Kurz <groug@kaod.org>
> ---
>  hw/ppc/spapr_events.c |   12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/ppc/spapr_events.c b/hw/ppc/spapr_events.c
> index ab9a1f0063d5..1a09dab6857d 100644
> --- a/hw/ppc/spapr_events.c
> +++ b/hw/ppc/spapr_events.c
> @@ -307,11 +307,13 @@ rtas_event_log_to_source(sPAPRMachineState *spapr, int log_type)
> 
>      switch (log_type) {
>      case RTAS_LOG_TYPE_HOTPLUG:
> -        source = spapr_event_sources_get_source(spapr->event_sources,
> -                                                EVENT_CLASS_HOT_PLUG);
> -        if (spapr_ovec_test(spapr->ov5_cas, OV5_HP_EVT)) {
> -            g_assert(source->enabled);
> -            break;
> +        if (spapr->use_hotplug_event_source) {
> +            source = spapr_event_sources_get_source(spapr->event_sources,
> +                                                    EVENT_CLASS_HOT_PLUG);
> +            if (spapr_ovec_test(spapr->ov5_cas, OV5_HP_EVT)) {
> +                g_assert(source->enabled);
> +                break;
> +            }
>          }
>          /* fall back to epow for legacy hotplug interrupt source */
>      case RTAS_LOG_TYPE_EPOW:
> 
> 

  parent reply	other threads:[~2019-03-01 16:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-01 14:17 [Qemu-devel] [PATCH] spapr: Explicitly check machine support before using EVENT_CLASS_HOT_PLUG Greg Kurz
2019-03-01 15:24 ` Thomas Huth
2019-03-01 16:16   ` Greg Kurz
2019-03-01 16:06 ` David Hildenbrand
2019-03-01 16:20 ` Michael Roth [this message]
2019-03-01 17:27   ` Greg Kurz

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=155145721677.30057.3700488922747499209@sif \
    --to=mdroth@linux.vnet.ibm.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=david@redhat.com \
    --cc=groug@kaod.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=thuth@redhat.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.