All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: Daniel Henrique Barboza <danielhb413@gmail.com>
Cc: Xujun Ma <xuma@redhat.com>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
	david@gibson.dropbear.id.au
Subject: Re: [PATCH v1 7/7] spapr.c: consider CPU core online state before allowing unplug
Date: Fri, 15 Jan 2021 18:22:16 +0100	[thread overview]
Message-ID: <20210115182216.6dccadee@bahia.lan> (raw)
In-Reply-To: <20210114180628.1675603-8-danielhb413@gmail.com>

On Thu, 14 Jan 2021 15:06:28 -0300
Daniel Henrique Barboza <danielhb413@gmail.com> wrote:

> The only restriction we have when unplugging CPUs is to forbid unplug of
> the boot cpu core. spapr_core_unplug_possible() does not contemplate the

I can't remember why this restriction was introduced in the first place...
This should be investigated and documented if the limitation still stands.

> possibility of some cores being offlined by the guest, meaning that we're
> rolling the dice regarding on whether we're unplugging the last online
> CPU core the guest has.
> 

Trying to unplug the last CPU is obviously something that deserves
special care. LoPAPR is quite explicit on the outcome : this should
terminate the partition.

13.7.4.1.1. Isolation of CPUs

The isolation of a CPU, in all cases, is preceded by the stop-self
RTAS function for all processor threads, and the OS insures that all
the CPU’s threads are in the RTAS stopped state prior to isolating the
CPU. Isolation of a processor that is not stopped produces unpredictable
results. The stopping of the last processor thread of a LPAR partition
effectively kills the partition, and at that point, ownership of all
partition resources reverts to the platform firmware.

R1-13.7.4.1.1-1. For the LRDR option: Prior to issuing the RTAS
set-indicator specifying isolate isolation-state of a CPU DR
connector type, all the CPU threads must be in the RTAS stopped
state.

R1-13.7.4.1.1-2. For the LRDR option: Stopping of the last processor
thread of a LPAR partition with the stop-self RTAS function, must kill
the partition, with ownership of all partition resources reverting to
the platform firmware.

This is clearly not how things work today : linux doesn't call
"stop-self" on the last vCPU and even if it did, QEMU doesn't
terminate the VM.

If there's a valid reason to not implement this PAPR behavior, I'd like
it to be documented.

> If we hit the jackpot, we're going to detach the core DRC and pulse the
> hotplug IRQ, but the guest OS will refuse to release the CPU. Our
> spapr_core_unplug() DRC release callback will never be called and the CPU
> core object will keep existing in QEMU. No error message will be sent
> to the user, but the CPU core wasn't unplugged from the guest.
> 
> If the guest OS onlines the CPU core again we won't be able to hotunplug it
> either. 'dmesg' inside the guest will report a failed attempt to offline an
> unknown CPU:
> 
> [  923.003994] pseries-hotplug-cpu: Failed to offline CPU <NULL>, rc: -16
> 
> This is the result of stopping the DRC state transition in the middle in the
> first failed attempt.
> 

Yes, at this point only a machine reset can fix things up.

Given this is linux's choice not to call "stop-self" as it should do, I'm not
super fan of hardcoding this logic in QEMU, unless there are really good
reasons to do so.

> We can avoid this, and potentially other bad things from happening, if we
> avoid to attempt the unplug altogether in this scenario. Let's check for
> the online/offline state of the CPU cores in the guest before allowing
> the hotunplug, and forbid removing a CPU core if it's the last one online
> in the guest.
> 
> Reported-by: Xujun Ma <xuma@redhat.com>
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1911414
> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
> ---
>  hw/ppc/spapr.c | 39 ++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 38 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index a2f01c21aa..d269dcd102 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -3709,9 +3709,16 @@ static void spapr_core_unplug(HotplugHandler *hotplug_dev, DeviceState *dev)
>  static int spapr_core_unplug_possible(HotplugHandler *hotplug_dev, CPUCore *cc,
>                                        Error **errp)
>  {
> +    CPUArchId *core_slot;
> +    SpaprCpuCore *core;
> +    PowerPCCPU *cpu;
> +    CPUState *cs;
> +    bool last_cpu_online = true;
>      int index;
>  
> -    if (!spapr_find_cpu_slot(MACHINE(hotplug_dev), cc->core_id, &index)) {
> +    core_slot = spapr_find_cpu_slot(MACHINE(hotplug_dev), cc->core_id,
> +                                    &index);
> +    if (!core_slot) {
>          error_setg(errp, "Unable to find CPU core with core-id: %d",
>                     cc->core_id);
>          return -1;
> @@ -3722,6 +3729,36 @@ static int spapr_core_unplug_possible(HotplugHandler *hotplug_dev, CPUCore *cc,
>          return -1;
>      }
>  
> +    /* Allow for any non-boot CPU core to be unplugged if already offline */
> +    core = SPAPR_CPU_CORE(core_slot->cpu);
> +    cs = CPU(core->threads[0]);
> +    if (cs->halted) {
> +        return 0;
> +    }
> +
> +    /*
> +     * Do not allow core unplug if it's the last core online.
> +     */
> +    cpu = POWERPC_CPU(cs);
> +    CPU_FOREACH(cs) {
> +        PowerPCCPU *c = POWERPC_CPU(cs);
> +
> +        if (c == cpu) {
> +            continue;
> +        }
> +
> +        if (!cs->halted) {
> +            last_cpu_online = false;
> +            break;
> +        }
> +    }
> +
> +    if (last_cpu_online) {
> +        error_setg(errp, "Unable to unplug CPU core with core-id %d: it is "
> +                   "the only CPU core online in the guest", cc->core_id);
> +        return -1;
> +    }
> +
>      return 0;
>  }
>  



  parent reply	other threads:[~2021-01-15 17:24 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14 18:06 [PATCH v1 0/7] pseries: avoid unplug the last online CPU core + assorted fixes Daniel Henrique Barboza
2021-01-14 18:06 ` [PATCH v1 1/7] spapr.h: fix trailing whitespace in phb_placement Daniel Henrique Barboza
2021-01-15  0:42   ` David Gibson
2021-01-14 18:06 ` [PATCH v1 2/7] spapr_hcall.c: make do_client_architecture_support static Daniel Henrique Barboza
2021-01-15  0:43   ` David Gibson
2021-01-14 18:06 ` [PATCH v1 3/7] spapr_rtas.c: fix identation in rtas_ibm_nmi_interlock() string Daniel Henrique Barboza
2021-01-15  0:44   ` David Gibson
2021-01-14 18:06 ` [PATCH v1 4/7] spapr_rtas.c: fix identation of rtas_ibm_suspend_me() args Daniel Henrique Barboza
2021-01-15  0:45   ` David Gibson
2021-01-14 18:06 ` [PATCH v1 5/7] spapr_cpu_core.c: use g_auto* in spapr_create_vcpu() Daniel Henrique Barboza
2021-01-15  0:49   ` David Gibson
2021-01-14 18:06 ` [PATCH v1 6/7] spapr.c: introduce spapr_core_unplug_possible() Daniel Henrique Barboza
2021-01-15  0:52   ` David Gibson
2021-01-14 18:06 ` [PATCH v1 7/7] spapr.c: consider CPU core online state before allowing unplug Daniel Henrique Barboza
2021-01-15  1:03   ` David Gibson
2021-01-15 17:22   ` Greg Kurz [this message]
2021-01-15 18:52     ` Daniel Henrique Barboza
2021-01-18  1:18       ` David Gibson
2021-01-18 10:28         ` Daniel Henrique Barboza
2021-01-15 21:43     ` Daniel Henrique Barboza
2021-01-15 21:43     ` Daniel Henrique Barboza
2021-01-18  1:12     ` David Gibson
2021-01-18 11:03       ` 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=20210115182216.6dccadee@bahia.lan \
    --to=groug@kaod.org \
    --cc=danielhb413@gmail.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=xuma@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.