qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Ying Fang <fangying1@huawei.com>
To: "Michael S. Tsirkin" <mst@redhat.com>, Andrew Jones <drjones@redhat.com>
Cc: peter.maydell@linaro.org, salil.mehta@huawei.com,
	zhang.zhanghailiang@huawei.com, qemu-devel@nongnu.org,
	shannon.zhaosl@gmail.com, Henglong Fan <fanhenglong@huawei.com>,
	alistair.francis@wdc.com, qemu-arm@nongnu.org,
	imammedo@redhat.com
Subject: Re: [RFC PATCH 4/5] hw/acpi/aml-build: add processor hierarchy node structure
Date: Thu, 4 Mar 2021 15:09:41 +0800	[thread overview]
Message-ID: <6ff19198-4ec7-dbc1-7553-6460271f50b0@huawei.com> (raw)
In-Reply-To: <20210301103619-mutt-send-email-mst@kernel.org>



On 3/1/2021 11:50 PM, Michael S. Tsirkin wrote:
> On Mon, Mar 01, 2021 at 10:39:19AM +0100, Andrew Jones wrote:
>> On Fri, Feb 26, 2021 at 10:23:03AM +0800, Ying Fang wrote:
>>>
>>>
>>> On 2/25/2021 7:47 PM, Andrew Jones wrote:
>>>> On Thu, Feb 25, 2021 at 04:56:26PM +0800, Ying Fang wrote:
>>>>> Add the processor hierarchy node structures to build ACPI information
>>>>> for CPU topology. Since the private resources may be used to describe
>>>>> cache hierarchy and it is variable among different topology level,
>>>>> three helpers are introduced to describe the hierarchy.
>>>>>
>>>>> (1) build_socket_hierarchy for socket description
>>>>> (2) build_processor_hierarchy for processor description
>>>>> (3) build_smt_hierarchy for thread (logic processor) description
>>>>>
>>>>> Signed-off-by: Ying Fang <fangying1@huawei.com>
>>>>> Signed-off-by: Henglong Fan <fanhenglong@huawei.com>
>>>>> ---
>>>>>    hw/acpi/aml-build.c         | 40 +++++++++++++++++++++++++++++++++++++
>>>>>    include/hw/acpi/acpi-defs.h | 13 ++++++++++++
>>>>>    include/hw/acpi/aml-build.h |  7 +++++++
>>>>>    3 files changed, 60 insertions(+)
>>>>>
>>>>> diff --git a/hw/acpi/aml-build.c b/hw/acpi/aml-build.c
>>>>> index a2cd7a5830..a0af3e9d73 100644
>>>>> --- a/hw/acpi/aml-build.c
>>>>> +++ b/hw/acpi/aml-build.c
>>>>> @@ -1888,6 +1888,46 @@ void build_slit(GArray *table_data, BIOSLinker *linker, MachineState *ms,
>>>>>                     table_data->len - slit_start, 1, oem_id, oem_table_id);
>>>>>    }
>>>>> +/*
>>>>> + * ACPI 6.3: 5.2.29.1 Processor hierarchy node structure (Type 0)
>>>>> + */
>>>>> +void build_socket_hierarchy(GArray *tbl, uint32_t parent, uint32_t id)
>>>>> +{
>>>>> +    build_append_byte(tbl, ACPI_PPTT_TYPE_PROCESSOR); /* Type 0 - processor */
>>>>> +    build_append_byte(tbl, 20);         /* Length, no private resources */
>>>>> +    build_append_int_noprefix(tbl, 0, 2);  /* Reserved */
>>>>> +    build_append_int_noprefix(tbl, ACPI_PPTT_PHYSICAL_PACKAGE, 4);
>>>>
>>>> Missing '/* Flags */'
>>>
>>> Will fix.
>>>
>>>>
>>>>> +    build_append_int_noprefix(tbl, parent, 4); /* Parent */
>>>>> +    build_append_int_noprefix(tbl, id, 4);     /* ACPI processor ID */
>>>>> +    build_append_int_noprefix(tbl, 0, 4);  /* Number of private resources */
>>>>> +}
>>>>> +
>>>>> +void build_processor_hierarchy(GArray *tbl, uint32_t flags,
>>>>> +                               uint32_t parent, uint32_t id)
>>>>> +{
>>>>> +    build_append_byte(tbl, ACPI_PPTT_TYPE_PROCESSOR);  /* Type 0 - processor */
>>>>> +    build_append_byte(tbl, 20);         /* Length, no private resources */
>>>>> +    build_append_int_noprefix(tbl, 0, 2);      /* Reserved */
>>>>> +    build_append_int_noprefix(tbl, flags, 4);  /* Flags */
>>>>> +    build_append_int_noprefix(tbl, parent, 4); /* Parent */
>>>>> +    build_append_int_noprefix(tbl, id, 4);     /* ACPI processor ID */
>>>>> +    build_append_int_noprefix(tbl, 0, 4);  /* Number of private resources */
>>>>> +}
>>>>> +
>>>>> +void build_thread_hierarchy(GArray *tbl, uint32_t parent, uint32_t id)
>>>>> +{
>>>>> +    build_append_byte(tbl, ACPI_PPTT_TYPE_PROCESSOR); /* Type 0 - processor */
>>>>> +    build_append_byte(tbl, 20);           /* Length, no private resources */
>>>>> +    build_append_int_noprefix(tbl, 0, 2); /* Reserved */
>>>>> +    build_append_int_noprefix(tbl,
>>>>> +                              ACPI_PPTT_ACPI_PROCESSOR_ID_VALID |
>>>>> +                              ACPI_PPTT_ACPI_PROCESSOR_IS_THREAD |
>>>>> +                              ACPI_PPTT_ACPI_LEAF_NODE, 4);  /* Flags */
>>>>> +    build_append_int_noprefix(tbl, parent , 4); /* parent */
>>>>
>>>> 'parent' not capitalized. We want these comments to exactly match the text
>>>> in the spec.
>>>
>>> Will fix.
>>>
>>>>
>>>>> +    build_append_int_noprefix(tbl, id, 4);      /* ACPI processor ID */
>>>>> +    build_append_int_noprefix(tbl, 0, 4);       /* Num of private resources */
>>>>> +}
>>>>> +
>>>>>    /* build rev1/rev3/rev5.1 FADT */
>>>>>    void build_fadt(GArray *tbl, BIOSLinker *linker, const AcpiFadtData *f,
>>>>>                    const char *oem_id, const char *oem_table_id)
>>>>> diff --git a/include/hw/acpi/acpi-defs.h b/include/hw/acpi/acpi-defs.h
>>>>> index cf9f44299c..45e10d886f 100644
>>>>> --- a/include/hw/acpi/acpi-defs.h
>>>>> +++ b/include/hw/acpi/acpi-defs.h
>>>>> @@ -618,4 +618,17 @@ struct AcpiIortRC {
>>>>>    } QEMU_PACKED;
>>>>>    typedef struct AcpiIortRC AcpiIortRC;
>>>>> +enum {
>>>>> +    ACPI_PPTT_TYPE_PROCESSOR = 0,
>>>>> +    ACPI_PPTT_TYPE_CACHE,
>>>>> +    ACPI_PPTT_TYPE_ID,
>>>>> +    ACPI_PPTT_TYPE_RESERVED
>>>>> +};
>>>>> +
>>>>> +#define ACPI_PPTT_PHYSICAL_PACKAGE          (1)
>>>>> +#define ACPI_PPTT_ACPI_PROCESSOR_ID_VALID   (1 << 1)
>>>>> +#define ACPI_PPTT_ACPI_PROCESSOR_IS_THREAD  (1 << 2)      /* ACPI 6.3 */
>>>>> +#define ACPI_PPTT_ACPI_LEAF_NODE            (1 << 3)      /* ACPI 6.3 */
>>>>> +#define ACPI_PPTT_ACPI_IDENTICAL            (1 << 4)      /* ACPI 6.3 */
> 
> You need to quote specific place in spec where this appeared, not
> just version. and what about previous ones?

Thanks, Will fix.

> 
> 
>>>>> +
>>>>>    #endif
>>>>> diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
>>>>> index 380d3e3924..7f0ca1a198 100644
>>>>> --- a/include/hw/acpi/aml-build.h
>>>>> +++ b/include/hw/acpi/aml-build.h
>>>>> @@ -462,6 +462,13 @@ void build_srat_memory(AcpiSratMemoryAffinity *numamem, uint64_t base,
>>>>>    void build_slit(GArray *table_data, BIOSLinker *linker, MachineState *ms,
>>>>>                    const char *oem_id, const char *oem_table_id);
>>>>> +void build_socket_hierarchy(GArray *tbl, uint32_t parent, uint32_t id);
>>>>> +
>>>>> +void build_processor_hierarchy(GArray *tbl, uint32_t flags,
>>>>> +                               uint32_t parent, uint32_t id);
>>>>> +
>>>>> +void build_thread_hierarchy(GArray *tbl, uint32_t parent, uint32_t id);
>>>>
>>>> Why does build_processor_hierarchy() take a flags argument, but the
>>>> others don't? Why not just have a single 'flags' taking function,
>>>> like [*] that works for all of them? I think that answer to that is
>>>
>>> Yes, you are right.
>>>
>>>> that when cache topology support is added it's better to break these
>>>> into separate functions, but should we do that now? It seems odd to
>>>> be introducing unused defines and this API before it's necessary.
>>> So it is better for us to keep just one common build_processor_hierarchy
>>> API here in your opinion.
>>
>> Well, a consistent API without unused defines. Whether or not that's
>> a single common function or not isn't that important.
>>
>> Thanks,
>> drew
> 
> Yes, the preferred way is code comments:
> E.g.
> 
>      build_append_byte(tbl, ACPI_PPTT_TYPE_PROCESSOR);  /* Type 0 - processor */
> 
> should be
> 
>      build_append_byte(tbl, 0);  /* Type 0 - processor */
> 
> 
> similar:
> 
>>>>> +    build_append_int_noprefix(tbl,
>>>>> +                              ACPI_PPTT_ACPI_PROCESSOR_ID_VALID |
>>>>> +                              ACPI_PPTT_ACPI_PROCESSOR_IS_THREAD |
>>>>> +                              ACPI_PPTT_ACPI_LEAF_NODE, 4);  /* Flags */
> 
> should be
> 
>   +    build_append_int_noprefix(tbl, /* Processor Structure Flags */
>   +                              (1 << 1)  /* ACPI Processor ID valid */|
>   +                              (1 << 2) /* Processor is a Thread */) |
>   +                              (1 << 3) /* Node is a Leaf */, 4);
> 
> where you would make sure the text matches the spec verbatim.
> 
> also note how for multi-line code comments precede the code.
> For single-line they can come after the code.

Thanks, will fix it as your suggestions.

> 
>>>
>>>>
>>>> [*] https://github.com/rhdrjones/qemu/commit/439b38d67ca1f2cbfa5b9892a822b651ebd05c11
>>>>
>>>> Thanks,
>>>> drew
>>>>
>>>>> +
>>>>>    void build_fadt(GArray *tbl, BIOSLinker *linker, const AcpiFadtData *f,
>>>>>                    const char *oem_id, const char *oem_table_id);
>>>>> -- 
>>>>> 2.23.0
>>>>>
>>>>>
>>>>
>>>> .
>>>>
>>>
>>> Thanks,
>>> Ying.
>>>
> 
> .
> 


  reply	other threads:[~2021-03-04  7:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-25  8:56 [RFC PATCH 0/5] hw/arm/virt: Introduce cpu topology support Ying Fang
2021-02-25  8:56 ` [RFC PATCH 1/5] device_tree: Add qemu_fdt_add_path Ying Fang
2021-02-25 11:03   ` Andrew Jones
2021-02-25 12:54     ` Ying Fang
2021-02-25 13:25       ` Andrew Jones
2021-02-25 13:39         ` Ying Fang
2021-02-25  8:56 ` [RFC PATCH 2/5] hw/arm/virt: Add cpu-map to device tree Ying Fang
2021-02-25 11:16   ` Andrew Jones
2021-02-25 13:18     ` Ying Fang
2021-02-25 14:30       ` Andrew Jones
2021-02-25  8:56 ` [RFC PATCH 3/5] hw/arm/virt-acpi-build: distinguish possible and present cpus Ying Fang
2021-02-25 11:26   ` Andrew Jones
2021-02-25  8:56 ` [RFC PATCH 4/5] hw/acpi/aml-build: add processor hierarchy node structure Ying Fang
2021-02-25 11:47   ` Andrew Jones
2021-02-26  2:23     ` Ying Fang
2021-03-01  9:39       ` Andrew Jones
2021-03-01 15:50         ` Michael S. Tsirkin
2021-03-04  7:09           ` Ying Fang [this message]
2021-02-25  8:56 ` [RFC PATCH 5/5] hw/arm/virt-acpi-build: add PPTT table Ying Fang
2021-02-25 11:38   ` Andrew Jones
2021-02-26  2:26     ` Ying Fang
2021-02-25 12:02 ` [RFC PATCH 0/5] hw/arm/virt: Introduce cpu topology support Andrew Jones
2021-02-26  8:41   ` Ying Fang
2021-03-01  9:48     ` Andrew Jones
2021-03-05  6:14       ` Ying Fang
     [not found] ` <20210310092059.blt3yymqi2eyc2ua@kamzik.brq.redhat.com>
2021-03-10  9:43   ` 答复: " fangying

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=6ff19198-4ec7-dbc1-7553-6460271f50b0@huawei.com \
    --to=fangying1@huawei.com \
    --cc=alistair.francis@wdc.com \
    --cc=drjones@redhat.com \
    --cc=fanhenglong@huawei.com \
    --cc=imammedo@redhat.com \
    --cc=mst@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=salil.mehta@huawei.com \
    --cc=shannon.zhaosl@gmail.com \
    --cc=zhang.zhanghailiang@huawei.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).