qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gu Zheng <guz.fnst@cn.fujitsu.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: chen.fan.fnst@cn.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com,
	tangchen@cn.fujitsu.com, qemu-devel@nongnu.org, afaerber@suse.de
Subject: Re: [Qemu-devel] [PATCH V3 7/7] acpi/cpu-hotplug: introduce help function to keep bit setting in one place
Date: Mon, 29 Sep 2014 17:22:08 +0800	[thread overview]
Message-ID: <542924C0.2030202@cn.fujitsu.com> (raw)
In-Reply-To: <20140926153717.1a87a0ee@nial.usersys.redhat.com>

Hi Igor,
On 09/26/2014 09:37 PM, Igor Mammedov wrote:

> On Wed, 17 Sep 2014 09:24:03 +0800
> Gu Zheng <guz.fnst@cn.fujitsu.com> wrote:
> 
>> Introduce help function acpi_set_local_sts() to simplify acpi_cpu_plug_cb
>> and acpi_cpu_hotplug_init, so that we can keep bit setting in one place.
>>
>> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
>> ---
>>  hw/acpi/cpu_hotplug.c |   22 +++++++++++++++-------
>>  1 files changed, 15 insertions(+), 7 deletions(-)
>>
>> diff --git a/hw/acpi/cpu_hotplug.c b/hw/acpi/cpu_hotplug.c
>> index 7629686..d42c961 100644
>> --- a/hw/acpi/cpu_hotplug.c
>> +++ b/hw/acpi/cpu_hotplug.c
>> @@ -36,8 +36,8 @@ static const MemoryRegionOps AcpiCpuHotplug_ops = {
>>      },
>>  };
>>  
>> -void acpi_cpu_plug_cb(ACPIREGS *ar, qemu_irq irq,
>> -                      AcpiCpuHotplug *g, CPUState *cpu, Error **errp)
>> +static void acpi_set_local_sts(AcpiCpuHotplug *g, CPUState *cpu,
>> +                               Error **errp)
>>  {
>>      CPUClass *k = CPU_GET_CLASS(cpu);
>>      int64_t cpu_id;
>> @@ -48,9 +48,18 @@ void acpi_cpu_plug_cb(ACPIREGS *ar, qemu_irq irq,
>>          return;
>>      }
>>  
>> -    ar->gpe.sts[0] |= ACPI_CPU_HOTPLUG_STATUS;
>>      g->sts[cpu_id / 8] |= (1 << (cpu_id % 8));
>> +}
>>  
>> +void acpi_cpu_plug_cb(ACPIREGS *ar, qemu_irq irq,
>> +                      AcpiCpuHotplug *g, CPUState *cpu, Error **errp)
>> +{
>> +    acpi_set_local_sts(g, cpu, errp);
>> +    if (*errp != NULL) {
>> +        return;
>> +    }
>> +
> 
>> +    ar->gpe.sts[0] |= ACPI_CPU_HOTPLUG_STATUS;
> ^^^ shouldn't be set for coldplugged CPUs along with IRQ below
> 
>>      acpi_update_sci(ar, irq);
>>  }
>>  
>> @@ -60,11 +69,10 @@ void acpi_cpu_hotplug_init(MemoryRegion *parent, Object *owner,
>>      CPUState *cpu;
>>  
>>      CPU_FOREACH(cpu) {
>> -        CPUClass *cc = CPU_GET_CLASS(cpu);
>> -        int64_t id = cc->get_arch_id(cpu);
>> +        Error *local_err = NULL;
>>  
>> -        g_assert((id / 8) < ACPI_GPE_PROC_LEN);
>> -        gpe_cpu->sts[id / 8] |= (1 << (id % 8));
>> +        acpi_set_local_sts(gpe_cpu, cpu, &local_err);
>> +        g_assert(local_err == NULL);
> Wouldn't acpi_cpu_plug_cb() do everything this FOREACH does?
> I've suggest to drop CPU_FOREACH() altogether.

I got your meaning: Make acpi_cpu_plug_cb serve all CPUs (both startup and hotpluged)
, and only triggers sci irq for hotpluged ones, so that we can drop the duplicated
operations in acpi_cpu_hotplug_init.
But one problem is that pcms->acpi_dev was registered after startup CPUs set realized, so
acpi_cpu_plug_cb can not serve startup CPUs.
I tried to switch the order, but it failed, because there are some internal dependences.
Now, I'm trying to split the startup CPUs init into two steps (init and realize), and
register pcms->acpi_dev between the two steps.
What's your opinion?

Thanks,
Gu

> 
>>      }
>>      memory_region_init_io(&gpe_cpu->io, owner, &AcpiCpuHotplug_ops,
>>                            gpe_cpu, "acpi-cpu-hotplug", ACPI_GPE_PROC_LEN);
> 
> .
> 

  reply	other threads:[~2014-09-29  9:36 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-17  1:23 [Qemu-devel] [PATCH V3 0/7] cpu/acpi: convert cpu hot plug to hotplug_handler API Gu Zheng
2014-09-17  1:23 ` [Qemu-devel] [PATCH V3 1/7] acpi/cpu: add cpu hotplug callback function to match " Gu Zheng
2014-09-26 13:08   ` Igor Mammedov
2014-09-17  1:23 ` [Qemu-devel] [PATCH V3 2/7] acpi:ich9: convert cpu hotplug handle to " Gu Zheng
2014-09-17  1:23 ` [Qemu-devel] [PATCH V3 3/7] acpi:piix4: " Gu Zheng
2014-09-17  1:24 ` [Qemu-devel] [PATCH V3 4/7] pc: add cpu hotplug handler to PC_MACHINE Gu Zheng
2014-09-26 13:06   ` Igor Mammedov
2014-09-29  2:58     ` Gu Zheng
2014-09-29  8:58       ` Igor Mammedov
2014-09-17  1:24 ` [Qemu-devel] [PATCH V3 5/7] pc: Update rtc_cmos in pc_cpu_plug Gu Zheng
2014-09-26 13:23   ` Igor Mammedov
2014-09-29  3:12     ` Gu Zheng
2014-09-26 13:29   ` Igor Mammedov
2014-09-17  1:24 ` [Qemu-devel] [PATCH V3 6/7] cpu-hotplug: rename function for better readability Gu Zheng
2014-09-17  1:24 ` [Qemu-devel] [PATCH V3 7/7] acpi/cpu-hotplug: introduce help function to keep bit setting in one place Gu Zheng
2014-09-26 13:37   ` Igor Mammedov
2014-09-29  9:22     ` Gu Zheng [this message]
2014-09-29  9:47       ` Igor Mammedov
2014-09-29  9:44         ` Gu Zheng
2014-09-29 10:19           ` Igor Mammedov
2014-09-18  9:55 ` [Qemu-devel] [PATCH V3 0/7] cpu/acpi: convert cpu hot plug to hotplug_handler API Gu Zheng
2014-09-24  2:23 ` Gu Zheng

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=542924C0.2030202@cn.fujitsu.com \
    --to=guz.fnst@cn.fujitsu.com \
    --cc=afaerber@suse.de \
    --cc=chen.fan.fnst@cn.fujitsu.com \
    --cc=imammedo@redhat.com \
    --cc=isimatu.yasuaki@jp.fujitsu.com \
    --cc=qemu-devel@nongnu.org \
    --cc=tangchen@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).