qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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&amp;data=02%7C01%7Cbabu.moger%40amd.com%7Cda1d1c9f34af4475596108d7b9795fef%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637181803279890359&amp;sdata=Z%2B%2BA2%2FMIVQZfGtUe1aBLzttCQnCpZKEwshOhoVAg1%2BU%3D&amp;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?
> 


  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).