From: Babu Moger <babu.moger@amd.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: mst@redhat.com, qemu-devel@nongnu.org, pbonzini@redhat.com,
Igor Mammedov <imammedo@redhat.com>,
rth@twiddle.net
Subject: Re: [PATCH v4 12/16] hw/i386: Use the apicid handlers from X86MachineState
Date: Mon, 24 Feb 2020 17:13:18 -0600 [thread overview]
Message-ID: <5931c329-79ea-1f9c-5df7-db06d930a0e4@amd.com> (raw)
In-Reply-To: <20200224223149.GF4440@habkost.net>
On 2/24/20 4:31 PM, Eduardo Habkost wrote:
> On Mon, Feb 24, 2020 at 11:58:09AM -0600, Babu Moger wrote:
>>
>>
>> On 2/24/20 11:19 AM, Igor Mammedov wrote:
>>> On Thu, 13 Feb 2020 12:17:46 -0600
>>> Babu Moger <babu.moger@amd.com> wrote:
>>>
>>>> Check and Load the apicid handlers from X86CPUDefinition if available.
>>>> Update the calling convention for the apicid handlers.
>>>
>>> Previous and this patch look too complicated for the task at the hand.
>>> In particular, cpu_x86_init_apicid_fns() from previous patch adds 1 more
>>> reference to Machine into i386/cpu.c (even though it's just a helper function)
>>> and I think un-necessary hooks to X86CPUDefinition (it's not really CPU's
>>> businesses to make up APIC-IDs).
>>>
>>> I'd rather do opposite and get rid of the last explicit dependency to
>>> ms->smp.cpus from cpu.c. But well, it's out of scope of this series,
>>> so for this series I'd just try to avoid adding more Machine dependencies.
>>>
>>> All 11/16 does is basically using hooks as a switch "I'm EPYC" to
>>> set epyc specific encoding topo routines.
>>>
>>> It could be accomplished by a simple Boolean flag like
>>> X86CPUDefinition::use_epyc_apic_id_encoding
>>>
>>> and then cpu_x86_init_apicid_fns() could be replaced with trivial
>>> helper like:
>>>
>>> x86_use_epyc_apic_id_encoding(char *cpu_type)
>>> {
>>> X86CPUClass *xcc = ... cpu_type ...
>>> return xcc->model->cpudef->use_epyc_apic_id_encoding
>>> }
>>>
>>> then machine could override default[1] hooks using this helper
>>> as the trigger
>>> x86_cpus_init()
>>> {
>>> // no need in dedicated function as it's the only instance it's going to be called ever
>>> if (x86_use_epyc_apic_id_encoding(ms->cpu_type)) {
>>> x86ms->apicid_from_cpu_idx = ...epyc...
>>> x86ms->topo_ids_from_apicid = ...epyc...
>>> x86ms->apicid_from_topo_ids = ...epyc...
>>> x86ms->apicid_pkg_offset = ...epyc...
>>> }
>>> }
>>>
>>> That would be less invasive and won't create non necessary dependencies.
>>
>> Yes. We can achieve the task here with your approach mentioned above. But,
>> we still will have a scaling issue. In future if a "new cpu model" comes
>> up its own decoding, then we need to add another bolean flag use_new
>> _cpu_apic_id_encoding. And then do that same check again. In that sense,
>> the current approach is bit generic. Lets also hear from Eduardo.
>
> To be honest, I really hope the number of APIC ID initialization
> variations won't grow in the future.
>
> In either case, X86MachineState really doesn't seem to be the
> right place to save the function pointers. Whether we choose a
> boolean flag or a collection of function pointers, model-specific
> information belong to x86CPUClass and/or X86CPUDefinition, not
> MachineState.
My bad. I completely missed that part. Yes. You mentioned that earlier.
I can move the functions pointers to X86CPUClass and initialize the
pointers from X86CPUDefinition. Thanks
>
> See the reply I sent at:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fqemu-devel%2F20200128200438.GJ18770%40habkost.net%2F&data=02%7C01%7Cbabu.moger%40amd.com%7Cda1d1c9f34af4475596108d7b9795fef%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637181803279890359&sdata=Z%2B%2BA2%2FMIVQZfGtUe1aBLzttCQnCpZKEwshOhoVAg1%2BU%3D&reserved=0
>
> ] If you need a CPU model to provide special behavior,
> ] you have two options:
> ]
> ] * Add a method pointer to X86CPUClass and/or X86CPUDefinition
> ] * Add a QOM property to enable/disable special behavior, and
> ] include the property in the CPU model definition.
> ]
> ] The second option might be preferable long term, but might
> ] require more work because the property would become visible in
> ] query-cpu-model-expansion and in the command line. The first
> ] option may be acceptable to avoid extra user-visible complexity
> ] in the first version.
> ]
> ]
> ]
> ] > + pcms->apicid_from_cpu_idx = x86_apicid_from_cpu_idx_epyc;
> ] > + pcms->topo_ids_from_apicid = x86_topo_ids_from_apicid_epyc;
> ] > + pcms->apicid_from_topo_ids = x86_apicid_from_topo_ids_epyc;
> ]
> ] Why do you need to override the function pointers in
> ] PCMachineState instead of just looking up the relevant info at
> ] X86CPUClass?
>
next prev parent reply other threads:[~2020-02-24 23:14 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-13 18:16 [PATCH v4 00/16] APIC ID fixes for AMD EPYC CPU model Babu Moger
2020-02-13 18:16 ` [PATCH v4 01/16] hw/i386: Rename X86CPUTopoInfo structure to X86CPUTopoIDs Babu Moger
2020-02-13 18:16 ` [PATCH v4 02/16] hw/i386: Introduce X86CPUTopoInfo to contain topology info Babu Moger
2020-02-13 18:16 ` [PATCH v4 03/16] hw/i386: Consolidate topology functions Babu Moger
2020-02-13 18:16 ` [PATCH v4 04/16] hw/i386: Introduce init_topo_info to initialize X86CPUTopoInfo Babu Moger
2020-02-21 17:05 ` Igor Mammedov
2020-02-21 17:51 ` Babu Moger
2020-02-24 8:18 ` Igor Mammedov
2020-02-24 16:54 ` Babu Moger
2020-02-13 18:16 ` [PATCH v4 05/16] machine: Add SMP Sockets in CpuTopology Babu Moger
2020-02-24 8:37 ` Igor Mammedov
2020-02-13 18:17 ` [PATCH v4 06/16] hw/i386: Update structures for nodes_per_pkg Babu Moger
2020-02-24 8:34 ` Igor Mammedov
2020-02-24 17:12 ` Babu Moger
2020-02-25 7:42 ` Igor Mammedov
2020-02-13 18:17 ` [PATCH v4 07/16] hw/i386: Rename apicid_from_topo_ids to x86_apicid_from_topo_ids Babu Moger
2020-02-20 12:43 ` Igor Mammedov
2020-02-13 18:17 ` [PATCH v4 08/16] hw/386: Add EPYC mode topology decoding functions Babu Moger
2020-02-24 8:50 ` Igor Mammedov
2020-02-24 17:24 ` Babu Moger
2020-02-13 18:17 ` [PATCH v4 09/16] target/i386: Cleanup and use the EPYC mode topology functions Babu Moger
2020-02-24 8:52 ` Igor Mammedov
2020-02-24 17:29 ` Babu Moger
2020-02-25 7:49 ` Igor Mammedov
2020-02-25 15:10 ` Babu Moger
2020-03-02 17:09 ` Babu Moger
2020-03-03 8:47 ` Igor Mammedov
2020-02-13 18:17 ` [PATCH v4 10/16] hw/i386: Introduce apicid functions inside X86MachineState Babu Moger
2020-02-24 17:01 ` Igor Mammedov
2020-02-24 17:30 ` Babu Moger
2020-02-13 18:17 ` [PATCH v4 11/16] target/i386: Load apicid model specific handlers from X86CPUDefinition Babu Moger
2020-02-13 18:17 ` [PATCH v4 12/16] hw/i386: Use the apicid handlers from X86MachineState Babu Moger
2020-02-24 17:19 ` Igor Mammedov
2020-02-24 17:58 ` Babu Moger
2020-02-24 22:31 ` Eduardo Habkost
2020-02-24 23:13 ` Babu Moger [this message]
2020-02-25 15:32 ` Eduardo Habkost
2020-02-25 15:41 ` Babu Moger
2020-02-25 8:16 ` Igor Mammedov
2020-02-25 15:26 ` Eduardo Habkost
2020-02-13 18:17 ` [PATCH v4 13/16] target/i386: Add EPYC model specific handlers Babu Moger
2020-02-13 18:17 ` [PATCH v4 14/16] hw/i386: Move arch_id decode inside x86_cpus_init Babu Moger
2020-02-13 18:18 ` [PATCH v4 15/16] i386: Fix pkg_id offset for EPYC cpu models Babu Moger
2020-02-13 18:18 ` [PATCH v4 16/16] tests: Update the Unit tests Babu Moger
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=5931c329-79ea-1f9c-5df7-db06d930a0e4@amd.com \
--to=babu.moger@amd.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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).