All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Greg Kurz <groug@kaod.org>
Cc: qemu-devel@nongnu.org, mst@redhat.com, pbonzini@redhat.com,
	david@gibson.dropbear.id.au, david@redhat.com, cohuck@redhat.com
Subject: Re: [Qemu-devel] [PATCH] pc: make sure that guest isn't able to unplug the first cpu
Date: Mon, 27 Aug 2018 16:25:12 +0200	[thread overview]
Message-ID: <20180827162512.14fff54b@redhat.com> (raw)
In-Reply-To: <20180827160239.54cc993a@bahia.lan>

On Mon, 27 Aug 2018 16:02:39 +0200
Greg Kurz <groug@kaod.org> wrote:

> On Mon, 27 Aug 2018 13:07:10 +0200
> Igor Mammedov <imammedo@redhat.com> wrote:
> 
> > The first cpu unplug wasn't ever supported and corresponding
> > monitor/qmp commands refuse to unplug it. However guest is able
> > to issue eject request either using following command:
> >   # echo 1 >/sys/devices/system/cpu/cpu0/firmware_node/eject  
> 
> I can't reproduce the issue with a pc guest and current master...
> 
> All I seem to get is an error in dmesg:
> 
> [   97.435446] processor cpu0: Offline failed.

To be able to unplug CPU0 one need to set CONFIG_BOOTPARAM_HOTPLUG_CPU0=y
(I've tested it with a RHLE7 kernel)
 
> > or directly writing to cpu hotplug registers, which makes
> > qemu crash with SIGSEGV following back trace:
> > 
> >    kvm_flush_coalesced_mmio_buffer ()
> >        while (ring->first != ring->last)
> >    ...
> >    qemu_flush_coalesced_mmio_buffer
> >    prepare_mmio_access
> >    flatview_read_continue
> >    flatview_read
> >    address_space_read_full
> >    address_space_rw
> >    kvm_cpu_exec(cpu!0)
> >    qemu_kvm_cpu_thread_fn
> > 
> > the reason for which is that ring == KVMState::coalesced_mmio_ring
> > happens to be a part of 1st CPU that was uplugged by guest.
> > 
> > Fix it by forbidding 1st cpu unplug from guest side and in addition
> > remove CPU0._EJ0 ACPI method to make clear that unplug of the first
> > CPU is not supported.
> > 
> > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > ---
> > CCing spapr and s390x folks in case targets need to prevent 1st CPU unplug as well
> >   
> 
> A spapr guest can _release_ the first cpu by doing something like:
> 
> # echo -n "/cpus/PowerPC,POWER8@0" > /sys/devices/system/cpu/release
> 
> But AFAIK, this doesn't unplug the cpu from a QEMU standpoint.
Good,
so only x86 fix should be fixed.


> > CC: mst@redhat.com
> > CC: pbonzini@redhat.com
> > CC: david@gibson.dropbear.id.au
> > CC: groug@kaod.org
> > CC: david@redhat.com
> > CC: cohuck@redhat.com
> > ---
> >  hw/acpi/cpu.c | 10 ++++++----
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/hw/acpi/cpu.c b/hw/acpi/cpu.c
> > index 5ae595e..4bb8371 100644
> > --- a/hw/acpi/cpu.c
> > +++ b/hw/acpi/cpu.c
> > @@ -117,7 +117,7 @@ static void cpu_hotplug_wr(void *opaque, hwaddr addr, uint64_t data,
> >              DeviceState *dev = NULL;
> >              HotplugHandler *hotplug_ctrl = NULL;
> >  
> > -            if (!cdev->cpu) {
> > +            if (!cdev->cpu || cdev->cpu == first_cpu) {
> >                  trace_cpuhp_acpi_ejecting_invalid_cpu(cpu_st->selector);
> >                  break;
> >              }
> > @@ -541,9 +541,11 @@ void build_cpus_aml(Aml *table, MachineState *machine, CPUHotplugFeatures opts,
> >                  aml_buffer(madt_buf->len, (uint8_t *)madt_buf->data)));
> >              g_array_free(madt_buf, true);
> >  
> > -            method = aml_method("_EJ0", 1, AML_NOTSERIALIZED);
> > -            aml_append(method, aml_call1(CPU_EJECT_METHOD, uid));
> > -            aml_append(dev, method);
> > +            if (CPU(arch_ids->cpus[i].cpu) != first_cpu) {
> > +                method = aml_method("_EJ0", 1, AML_NOTSERIALIZED);
> > +                aml_append(method, aml_call1(CPU_EJECT_METHOD, uid));
> > +                aml_append(dev, method);
> > +            }
> >  
> >              method = aml_method("_OST", 3, AML_SERIALIZED);
> >              aml_append(method,  
> 

  reply	other threads:[~2018-08-27 14:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-27 11:07 [Qemu-devel] [PATCH] pc: make sure that guest isn't able to unplug the first cpu Igor Mammedov
2018-08-27 11:10 ` David Hildenbrand
2018-08-27 14:02 ` Greg Kurz
2018-08-27 14:25   ` Igor Mammedov [this message]
2018-08-28  0:52   ` David Gibson
2018-08-28 13:18     ` Igor Mammedov
2018-08-29  2:54       ` David Gibson
2018-08-29  8:43         ` Igor Mammedov
2018-08-29 13:15           ` Michael S. Tsirkin
2018-08-29 13:51             ` Igor Mammedov
2018-08-29 15:23               ` Laszlo Ersek
2018-09-07 20:52               ` Michael S. Tsirkin
2018-09-10  8:21                 ` Igor Mammedov

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=20180827162512.14fff54b@redhat.com \
    --to=imammedo@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=david@redhat.com \
    --cc=groug@kaod.org \
    --cc=mst@redhat.com \
    --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 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.