Re: [Qemu-devel] [PATCH v3 10/19] pc: register created initial and hotpluged CPUs in one place pc_cpu_plug()

[Eduardo Habkost]

On Thu, Jul 14, 2016 at 05:40:47PM +0200, Igor Mammedov wrote:
> On Thu, 14 Jul 2016 12:03:19 -0300
> Eduardo Habkost <address@hidden> 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 <address@hidden> wrote:
> > >   
> > > > On Wed, Jul 13, 2016 at 06:59:21PM -0400, Bandan Das wrote:  
> > > > > Eduardo Habkost <address@hidden> writes:
> > > > >     
> > > > > > On Wed, Jul 13, 2016 at 06:32:27PM -0400, Bandan Das wrote:    
> > > > > >> Igor Mammedov <address@hidden> 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 <address@hidden>
> > 
> > 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.

> 
> And I obviously don't want to push ACPI runtime state into generic
> possible_cpus.

Right.

-- 
Eduardo