All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: Gustavo Romero <gromero@linux.ibm.com>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v2 3/6] spapr/xive: Add a warning when StoreEOI is activated on POWER9 CPUs
Date: Wed, 7 Oct 2020 10:56:30 +0200	[thread overview]
Message-ID: <20201007105630.64e2f0c3@bahia.lan> (raw)
In-Reply-To: <e8013373-4536-08e4-27c9-8c8b8f46f768@kaod.org>

On Tue, 6 Oct 2020 19:03:28 +0200
Cédric Le Goater <clg@kaod.org> wrote:

> On 10/6/20 6:58 PM, Greg Kurz wrote:
> > On Mon, 5 Oct 2020 18:51:44 +0200
> > Cédric Le Goater <clg@kaod.org> wrote:
> > 
> >> StoreEOI on POWER9 CPUs is racy because load-after-store ordering is
> >> not enforced.
> >>
> >> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> >> ---
> >>  hw/ppc/spapr_caps.c | 9 +++++++++
> >>  1 file changed, 9 insertions(+)
> >>
> >> diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
> >> index b0a9d0227db2..9251badbdc27 100644
> >> --- a/hw/ppc/spapr_caps.c
> >> +++ b/hw/ppc/spapr_caps.c
> >> @@ -549,6 +549,15 @@ static void cap_storeeoi_apply(SpaprMachineState *spapr, uint8_t val,
> >>              error_setg(errp, "StoreEOI not supported by KVM");
> >>              return;
> >>          }
> >> +
> >> +        /*
> >> +         * load-after-store ordering is not enforced on POWER9 CPUs
> >> +         * and StoreEOI can be racy.
> >> +         */
> >> +        if (!ppc_type_check_compat(machine->cpu_type, CPU_POWERPC_LOGICAL_3_10,
> >> +                                  0, spapr->max_compat_pvr)) {
> >> +            warn_report("StoreEOI on a POWER9 CPU is unsafe on KVM.");
> > 

The error message should mention XIVE KVM device actually since this only
depends on kernel-irqchip.

> > It all boils down to what "unsafe" really means here... if the outcome is
> > "very likely hang the guest" as soon as it starts doing I/O, shouldn't
> > we error out instead ? What is the motivation to use StoreEOI if the
> > processor doesn't really support it ?
> 
> We use it in the lab on P9. We have never seen it failed even under stress. 
> But there is a possible race in the logic. 
> 
> C.

Thinking again. P9 boston systems on the field only use emulated XIVE and
we certainly want to be able to migrate to P9 systems that use in-kernel
XIVE and vice-versa. So, even if StoreEOI is technically supported by
the emulated XIVE, maybe we should disallow it anyway ?


  reply	other threads:[~2020-10-07  8:58 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-05 16:51 [PATCH v2 0/6] spapr/xive: Activate StoreEOI in P10 compat guests Cédric Le Goater
2020-10-05 16:51 ` [PATCH v2 1/6] spapr/xive: Introduce a StoreEOI capability Cédric Le Goater
2020-10-06 16:42   ` Greg Kurz
2020-10-07  5:59     ` Cédric Le Goater
2020-10-07  7:24       ` Greg Kurz
2020-10-05 16:51 ` [PATCH v2 2/6] spapr/xive: Add a warning when StoreEOI is activated on POWER8 CPUs Cédric Le Goater
2020-10-06 16:52   ` Greg Kurz
2020-10-05 16:51 ` [PATCH v2 3/6] spapr/xive: Add a warning when StoreEOI is activated on POWER9 CPUs Cédric Le Goater
2020-10-06 16:58   ` Greg Kurz
2020-10-06 17:03     ` Cédric Le Goater
2020-10-07  8:56       ` Greg Kurz [this message]
2020-10-07  9:21         ` Cédric Le Goater
2020-10-05 16:51 ` [PATCH v2 4/6] spapr/xive: Enforce load-after-store ordering Cédric Le Goater
2020-10-06 17:02   ` Greg Kurz
2020-10-05 16:51 ` [PATCH v2 5/6] spapr/xive: Activate StoreEOI at the source level Cédric Le Goater
2020-10-06 17:06   ` Greg Kurz
2020-10-06 17:41     ` Cédric Le Goater
2020-10-07  7:26       ` Greg Kurz
2020-10-05 16:51 ` [PATCH v2 6/6] spapr/xive: Introduce a new CAS value for the StoreEOI capability Cédric Le Goater
2020-10-06 17:39   ` Greg Kurz
2020-10-06 17:56     ` Cédric Le Goater
2020-10-07 13:43       ` Greg Kurz
2020-10-07 14:28         ` Cédric Le Goater
2020-10-09  0:23 ` [PATCH v2 0/6] spapr/xive: Activate StoreEOI in P10 compat guests David Gibson
2020-10-09  5:57   ` Cédric Le Goater
2020-10-12  5:38     ` David Gibson
2020-11-02 13:22   ` Cédric Le Goater
2020-11-23  6:44     ` David Gibson
2020-11-23 11:16       ` Cédric Le Goater

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=20201007105630.64e2f0c3@bahia.lan \
    --to=groug@kaod.org \
    --cc=clg@kaod.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=gromero@linux.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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 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.