On Thu, 14 Jul 2016 13:43:29 -0300
Eduardo Habkost <ehabk...@redhat.com> wrote:
> On Thu, Jul 14, 2016 at 05:40:47PM +0200, Igor Mammedov wrote:
> > On Thu, 14 Jul 2016 12:03:19 -0300
> > Eduardo Habkost <ehabk...@redhat.com> wrote:
> >
> > > On Thu, Jul 14, 2016 at 11:18:36AM +0200, Igor Mammedov wrote:
> > > > On Wed, 13 Jul 2016 20:37:13 -0300
> > > > Eduardo Habkost <ehabk...@redhat.com> wrote:
> > > >
> > > > > On Wed, Jul 13, 2016 at 06:59:21PM -0400, Bandan Das wrote:
> > > > > > Eduardo Habkost <ehabk...@redhat.com> writes:
> > > > > >
> > > > > > > On Wed, Jul 13, 2016 at 06:32:27PM -0400, Bandan Das wrote:
> > > > > > >> Igor Mammedov <imamm...@redhat.com> writes:
> > > > > > >>
> > > > > > >> > consolidate possible_cpus array management in pc_cpu_plug()
> > > > > > >> > for smp_cpus, coldplugged with -device and hotplugged with
> > > > > > >> > device_add.
> > > > > > >>
> > > > > > >> So, this takes care of the hotplug case and 09/19 took care of
> > > > > > >> the
> > > > > > >> coldplug case, right ? If yes, we should probably modify this
> > > > > > >> commit
> > > > > > >> message a little.
> > > > > > >
> > > > > > > This makes pc_cpu_plug() take care of both: now it will handle
> > > > > > > the coldplug case also (in addition to the hotplug case, that it
> > > > > > > already handled). I don't understand what you mean.
> > > > > > >
> > > > > > > Are you talking about the rtc_set_memory() call, only? This seems
> > > > > > > to be the only hotplug-specific code that still remains, in this
> > > > > > >
> > > > > >
> > > > > > Right, I thought the rtc_set_memory() call in 09/19 takes care of
> > > > > > the
> > > > > > case when the user boots with "-device" and this takes care of the
> > > > > > case
> > > > > > when user invokes device_add, no ?
> > > > >
> > > > > Yes for rtc_set_memory(). But the main purpose of this patch is
> > > > > to reuse all the rest of pc_cpu_plug() (i.e. everything except
> > > > > for the rtc_set_memory() call) for the coldplug CPUs too.
> > > > >
> > > > > Note that I didn't review the patch completely, yet. The
> > > > > replacement for the possible_cpus code looks OK, but I didn't
> > > > > check if it is safe to call
> > > > > HOTPLUG_HANDLER_GET_CLASS(pcms->acpi_dev)->plug() for coldplugged
> > > > > CPUs too.
> > > > for cpus created at pc_cpus_init() time, that path is unreachable
> > > > since pcms->acpi_dev == NULL,
> > >
> > > Sounds fragile, as it requires specific initialization ordering
> > > in the pc_cpus_init() caller. But:
> > >
> > > >
> > > > even if in the future that path becomes reachable
> > > > (when we could specify all CPUs including BSP with -device, it doesn't
> > > > work for BSP yet)
> > > > i.e. pcms->acpi_dev != NULL
> > > > then acpi_device will have be initialized see cpu_hotplug_hw_init()
> > > > and following plug handler will be called acpi_cpu_plug_cb() doing what
> > > > it was supposed to do.
> > >
> > > For reference for others, acpi_cpu_plug_cb() is:
> > >
> > > void acpi_cpu_plug_cb(HotplugHandler *hotplug_dev,
> > > CPUHotplugState *cpu_st, DeviceState *dev, Error
> > > **errp)
> > > {
> > > AcpiCpuStatus *cdev;
> > >
> > > cdev = get_cpu_status(cpu_st, dev);
> > > if (!cdev) {
> > > return;
> > > }
> > >
> > > cdev->cpu = CPU(dev);
> > > if (dev->hotplugged) {
> > > cdev->is_inserting = true;
> > > acpi_send_event(DEVICE(hotplug_dev), ACPI_CPU_HOTPLUG_STATUS);
> > > }
> > > }
> > >
> > > get_cpu_status() should return non-NULL for all possible CPUs. So the
> > > only code
> > > for coldplug case is cdev->cpu = CPU(dev), which is really something we
> > > want to
> > > run.
> > >
> > > So, that means it works properly on both cases: if pcms->acpi_dev==NULL
> > > and if
> > > pcms->acpi_dev != NULL.
> > >
> > > Reviewed-by: Eduardo Habkost <ehabk...@redhat.com>
> > >
> > > Related question: why does CPUHotplugState needs to duplicate the list of
> > > (CPUState *cpu, uint64_t arch_id) pairs, if PCMachineState already
> > > maintains a
> > > list with exactly the same information?
> > It maintains an array of AcpiCpuStatus, which is not only what
> > PCMachineState::possible_cpus is but an additional ACPI related
> > hot-plug state for each possible CPU.
> >
> > Probably PCMachineState::possible_cpus could be used in hw/acpi/cpu.c
> > but I've not looked at it. It doesn't look like directly accessing
> > PCMachineState::possible_cpus would give anything beside leaving out
> > managing AcpiCpuStatus.cpu (which serves as present/missing flag beside
> > of providing direct access to CPU instance when needed).
>
> Yeah, it looks like all we could get from it is the removal of
> the 'cdev->cpu = CPU(dev)' line from acpi_cpu_plug_cb(). Maybe
> later, if we have other reasons for a generic (and efficient)
> arch_id->CPU lookup mechanism in MachineState.
yep, I have an idea to replace lookups of apic_id by reverse conversion
of apic_id to index in possible_cpus, but yep it's material for 2.8
>
> >
> > And I obviously don't want to push ACPI runtime state into generic
> > possible_cpus.
>
> Right.
>
