All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: qemu-devel@nongnu.org, kraxel@redhat.com,
	liuxiaojian6@huawei.com, mst@redhat.com, rkrcmar@redhat.com,
	peterx@redhat.com, kevin@koconnor.net, pbonzini@redhat.com,
	lersek@redhat.com, chao.gao@intel.com
Subject: Re: [Qemu-devel] [PATCH v3 04/13] acpi: cphp: force switch to modern cpu hotplug if APIC ID > 254
Date: Tue, 18 Oct 2016 17:23:04 +0200	[thread overview]
Message-ID: <20161018172304.2388c550@nial.brq.redhat.com> (raw)
In-Reply-To: <20161018150551.GY3275@thinpad.lan.raisama.net>

On Tue, 18 Oct 2016 13:05:51 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Tue, Oct 18, 2016 at 04:34:53PM +0200, Igor Mammedov wrote:
> > On Tue, 18 Oct 2016 11:38:31 -0200
> > Eduardo Habkost <ehabkost@redhat.com> wrote:
> >   
> > > On Thu, Oct 13, 2016 at 11:52:38AM +0200, Igor Mammedov wrote:  
> > > > Switch to modern cpu hotplug at machine startup time if
> > > > a cpu present at boot has apic-id in range unsupported
> > > > by legacy cpu hotplug interface (i.e. > 254), to avoid
> > > > killing QEMU from legacy cpu hotplug code with error:
> > > >    "acpi: invalid cpu id: #apic-id#"
> > > > 
> > > > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > > > ---
> > > >  hw/acpi/cpu_hotplug.c | 10 ++++++----
> > > >  1 file changed, 6 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/hw/acpi/cpu_hotplug.c b/hw/acpi/cpu_hotplug.c
> > > > index e19d902..c2ab9b8 100644
> > > > --- a/hw/acpi/cpu_hotplug.c
> > > > +++ b/hw/acpi/cpu_hotplug.c
> > > > @@ -63,7 +63,8 @@ static void acpi_set_cpu_present_bit(AcpiCpuHotplug *g, CPUState *cpu,
> > > >  
> > > >      cpu_id = k->get_arch_id(cpu);
> > > >      if ((cpu_id / 8) >= ACPI_GPE_PROC_LEN) {
> > > > -        error_setg(errp, "acpi: invalid cpu id: %" PRIi64, cpu_id);
> > > > +        object_property_set_bool(g->device, false, "cpu-hotplug-legacy",
> > > > +                                 &error_abort);    
> > > 
> > > What happens we are in legacy mode and this is triggered during
> > > hotplug instead of machine init? Would it break something, or is
> > > it safe?  
> >  case 1: guest with legacy hotplug AML (migrated for example) would use
> >          legacy interface and it won't be possible to trigger this path
> >          as target should be started with the same CLI as source
> >          (hence < 255 cpus)
> >  case 2: guest started on new QEMU will have new hotplug AML which switches
> >          QEMU to modern cpu hotplug interface at ACPI tables _INI time
> >          so this path is unreachable.  
> 
> I see. Thanks for the explanation!
> 
> > 
> > Originally it's been static rule:
> >     since 2.7 use new hotplug interface and old one for older machine types
> > Well it's complex but Michael insisted on keeping legacy hotplug
> > by default and do dynamic switching, so here we are.
> >   
> 
> This means PCMachineClass::legacy_cpu_hotplug means "legacy CPU
> hotplug _only_", because legacy CPU hotplug is always available
> on startup, right?
Sorry, I can't parse question, could you rephrase?

> 
> > this behavior is since 2.7:
> >     commit 679dd1a957df418453efdd3ed2914dba5cd73773
> >     pc: use new CPU hotplug interface since 2.7 machine type
> > 
> >    
> > > Unrelated to this patch: piix4_set_cpu_hotplug_legacy() has an
> > > assert(!value). I assume this means we must replace the QOM
> > > property with something that the user can't fiddle with, right?  
> > it's readonly to user after machine starts, but allows user
> > to play modern hotplug interface on old machine types if needed.
> > assert is there to trap mistake of switching to legacy mode
> > (which is default) from compat_properties.  
> 
> What exactly makes the property read-only to the user? Maybe we
> should make the setter return an error instead, as all
> object_property_set_bool("cpu-hotplug-legacy") calls already use
> &error_abort?
My mistake,
it's dynamic property with custom setters in piix4/ich9_pm and user
potentially can write there.

I was under impression that errors are ignored if property comes from
compat_props, if returning error would prevent machine from starting
when property comes from compat_props I can fix cpu-hotplug-legacy to
return error.

> 
> >   
> > >   
> > > >          return;
> > > >      }
> > > >  
> > > > @@ -85,13 +86,14 @@ void legacy_acpi_cpu_hotplug_init(MemoryRegion *parent, Object *owner,
> > > >  {
> > > >      CPUState *cpu;
> > > >  
> > > > -    CPU_FOREACH(cpu) {
> > > > -        acpi_set_cpu_present_bit(gpe_cpu, cpu, &error_abort);
> > > > -    }
> > > >      memory_region_init_io(&gpe_cpu->io, owner, &AcpiCpuHotplug_ops,
> > > >                            gpe_cpu, "acpi-cpu-hotplug", ACPI_GPE_PROC_LEN);
> > > >      memory_region_add_subregion(parent, base, &gpe_cpu->io);
> > > >      gpe_cpu->device = owner;
> > > > +
> > > > +    CPU_FOREACH(cpu) {
> > > > +        acpi_set_cpu_present_bit(gpe_cpu, cpu, &error_abort);
> > > > +    }
> > > >  }
> > > >  
> > > >  void acpi_switch_to_modern_cphp(AcpiCpuHotplug *gpe_cpu,
> > > > -- 
> > > > 2.7.4
> > > >     
> > >   
> >   
> 

  reply	other threads:[~2016-10-18 15:23 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-13  9:52 [Qemu-devel] [PATCH v3 00/13] pc: q35: x2APIC support in kvm_apic mode Igor Mammedov
2016-10-13  9:52 ` [Qemu-devel] [PATCH v3 01/13] pc: acpi: x2APIC support for MADT table Igor Mammedov
2016-10-18 12:47   ` Eduardo Habkost
2016-10-18 13:00     ` Igor Mammedov
2016-10-18 13:05     ` Eduardo Habkost
2016-10-18 13:42       ` Igor Mammedov
2016-10-13  9:52 ` [Qemu-devel] [PATCH v3 02/13] pc: acpi: x2APIC support for SRAT table Igor Mammedov
2016-10-18 13:07   ` Eduardo Habkost
2016-10-18 13:47     ` Igor Mammedov
2016-10-13  9:52 ` [Qemu-devel] [PATCH v3 03/13] acpi: cphp: support x2APIC entry in cpu._MAT Igor Mammedov
2016-10-18 13:34   ` Eduardo Habkost
2016-10-18 13:46     ` Igor Mammedov
2016-10-18 13:47       ` Eduardo Habkost
2016-10-18 14:02         ` Igor Mammedov
2016-10-13  9:52 ` [Qemu-devel] [PATCH v3 04/13] acpi: cphp: force switch to modern cpu hotplug if APIC ID > 254 Igor Mammedov
2016-10-18 13:38   ` Eduardo Habkost
2016-10-18 14:34     ` Igor Mammedov
2016-10-18 15:05       ` Eduardo Habkost
2016-10-18 15:23         ` Igor Mammedov [this message]
2016-10-18 16:37           ` Eduardo Habkost
2016-10-19 10:35             ` Igor Mammedov
2016-10-13  9:52 ` [Qemu-devel] [PATCH v3 05/13] pc: leave max apic_id_limit only in legacy cpu hotplug code Igor Mammedov
2016-10-17 21:44   ` Eduardo Habkost
2016-10-18  9:02     ` Igor Mammedov
2016-10-18 10:31       ` Eduardo Habkost
2016-10-18 11:37         ` [Qemu-devel] [PATCH v4 " Igor Mammedov
2016-10-18 12:01           ` Eduardo Habkost
2016-10-18  9:12     ` [Qemu-devel] [PATCH v3 " Igor Mammedov
2016-10-18 10:39       ` Eduardo Habkost
2016-10-18 12:10         ` Igor Mammedov
2016-10-13  9:52 ` [Qemu-devel] [PATCH v3 06/13] pc: apic_common: extend APIC ID property to 32bit Igor Mammedov
2016-10-18 10:56   ` Eduardo Habkost
2016-10-18 12:36     ` Igor Mammedov
2016-10-18 12:59       ` Eduardo Habkost
2016-10-18 14:01         ` Igor Mammedov
2016-10-18 14:14           ` Eduardo Habkost
2016-10-18 14:38             ` Igor Mammedov
2016-10-13  9:52 ` [Qemu-devel] [PATCH v3 07/13] pc: apic_common: restore APIC ID to initial ID on reset Igor Mammedov
2016-10-13  9:52 ` [Qemu-devel] [PATCH v3 08/13] pc: apic_common: reset APIC ID to initial ID when switching into x2APIC mode Igor Mammedov
2016-10-13 14:11   ` Radim Krčmář
2016-10-13  9:52 ` [Qemu-devel] [PATCH v3 09/13] pc: kvm_apic: pass APIC ID depending on xAPIC/x2APIC mode Igor Mammedov
2016-10-13 14:08   ` Radim Krčmář
2016-10-14 11:21     ` [Qemu-devel] [PATCH v4 " Igor Mammedov
2016-10-17 12:35       ` Radim Krčmář
2016-10-18 14:56       ` Eduardo Habkost
2016-10-18 16:26         ` Radim Krčmář
2016-10-18 18:04           ` Eduardo Habkost
2016-10-17 21:51   ` [Qemu-devel] [PATCH v3 " Eduardo Habkost
2016-10-18  7:17     ` Igor Mammedov
2016-10-18 10:40       ` Eduardo Habkost
2016-10-13  9:52 ` [Qemu-devel] [PATCH v3 10/13] pc: clarify FW_CFG_MAX_CPUS usage comment Igor Mammedov
2016-10-13  9:52 ` [Qemu-devel] [PATCH v3 11/13] increase MAX_CPUMASK_BITS from 255 to 288 Igor Mammedov
2016-10-13 13:01   ` Andrew Jones
2016-10-13  9:52 ` [Qemu-devel] [PATCH v3 12/13] pc: add 'etc/boot-cpus' fw_cfg file for machine with more than 255 CPUs Igor Mammedov
2016-10-13  9:52 ` [Qemu-devel] [PATCH v3 13/13] pc: require IRQ remapping and EIM if there could be x2APIC CPUs Igor Mammedov
2016-10-13 13:56   ` Radim Krčmář
2016-10-14 11:25     ` [Qemu-devel] [PATCH v4 " Igor Mammedov
2016-10-18 11:27       ` Eduardo Habkost
2016-10-18 12:44         ` Igor Mammedov
2016-10-18 12:55           ` Eduardo Habkost
2016-10-18 14:39             ` Igor Mammedov
2016-10-13 10:01 ` [Qemu-devel] [PATCH v3 00/13] pc: q35: x2APIC support in kvm_apic mode Paolo Bonzini
2016-10-13 10:15   ` Igor Mammedov
2016-10-13 10:28   ` Gerd Hoffmann
2016-10-13 13:24 ` [Qemu-devel] [PATCH v3 14/13] pc: q35: bump max_cpus to 288 Igor Mammedov
2016-10-13 13:53   ` Radim Krčmář
2016-10-14  4:05 ` [Qemu-devel] [PATCH v3 00/13] pc: q35: x2APIC support in kvm_apic mode no-reply
2016-10-14  7:59   ` 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=20161018172304.2388c550@nial.brq.redhat.com \
    --to=imammedo@redhat.com \
    --cc=chao.gao@intel.com \
    --cc=ehabkost@redhat.com \
    --cc=kevin@koconnor.net \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=liuxiaojian6@huawei.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rkrcmar@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.