From: Eduardo Habkost <ehabkost@redhat.com>
To: Babu Moger <babu.moger@amd.com>
Cc: mst@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org,
imammedo@redhat.com, pbonzini@redhat.com, rth@twiddle.net
Subject: Re: [PATCH v3 16/18] hw/i386: Introduce EPYC mode function handlers
Date: Wed, 29 Jan 2020 11:41:54 -0500 [thread overview]
Message-ID: <20200129164154.GP18770@habkost.net> (raw)
In-Reply-To: <90118d85-941f-52f1-1976-0831ed3378c4@amd.com>
On Tue, Jan 28, 2020 at 03:48:15PM -0600, Babu Moger wrote:
> On 1/28/20 2:04 PM, Eduardo Habkost wrote:
[...]
> > 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.
>
> Yes. We need to have a special behavior for specific model.
> I will look at both these above approaches closely. Challenge is this
> needs to be done much early in the initialization(before parse_numa_opts
> or machine_run_board_init). Will research more on this.
You should be able to look up the requested CPU model using
object_class_by_name(machine->cpu_type). If you do this inside
x86-specific code before calling
apicid_from_cpu_idx/topo_ids_from_apicid/apicid_from_topo_ids,
you probably won't need a init_apicid_fn hook.
--
Eduardo
next prev parent reply other threads:[~2020-01-29 16:42 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-04 0:36 [PATCH v3 00/18] APIC ID fixes for AMD EPYC CPU models Babu Moger
2019-12-04 0:37 ` [PATCH v3 01/18] hw/i386: Rename X86CPUTopoInfo structure to X86CPUTopoIDs Babu Moger
2020-02-03 15:08 ` Igor Mammedov
2020-02-03 18:25 ` Babu Moger
2019-12-04 0:37 ` [PATCH v3 02/18] hw/i386: Introduce X86CPUTopoInfo to contain topology info Babu Moger
2020-01-28 15:44 ` Igor Mammedov
2019-12-04 0:37 ` [PATCH v3 03/18] hw/i386: Consolidate topology functions Babu Moger
2020-01-28 15:46 ` Igor Mammedov
2019-12-04 0:37 ` [PATCH v3 04/18] hw/i386: Introduce initialize_topo_info to initialize X86CPUTopoInfo Babu Moger
2020-01-28 15:49 ` Igor Mammedov
2020-01-28 16:42 ` Babu Moger
2019-12-04 0:37 ` [PATCH v3 05/18] machine: Add SMP Sockets in CpuTopology Babu Moger
2019-12-04 0:37 ` [PATCH v3 06/18] hw/core: Add core complex id in X86CPU topology Babu Moger
2020-01-28 16:27 ` Igor Mammedov
2020-01-28 16:44 ` Babu Moger
2020-01-28 16:31 ` Eric Blake
2020-01-28 16:44 ` Babu Moger
2019-12-04 0:37 ` [PATCH v3 07/18] machine: Add a new function init_apicid_fn in MachineClass Babu Moger
2020-01-28 16:29 ` Igor Mammedov
2020-01-28 19:45 ` Babu Moger
2020-01-28 20:12 ` Eduardo Habkost
2020-01-29 9:14 ` Igor Mammedov
2020-01-29 16:17 ` Babu Moger
2020-02-03 15:17 ` Igor Mammedov
2020-02-03 21:49 ` Babu Moger
2020-02-04 7:38 ` Igor Mammedov
2020-01-29 16:32 ` Babu Moger
2020-01-29 16:51 ` Eduardo Habkost
2020-01-29 17:05 ` Babu Moger
2019-12-04 0:37 ` [PATCH v3 08/18] hw/i386: Update structures for nodes_per_pkg Babu Moger
2019-12-04 0:37 ` [PATCH v3 09/18] i386: Add CPUX86Family type in CPUX86State Babu Moger
2019-12-04 0:38 ` [PATCH v3 10/18] hw/386: Add EPYC mode topology decoding functions Babu Moger
2019-12-04 0:38 ` [PATCH v3 11/18] i386: Cleanup and use the EPYC mode topology functions Babu Moger
2019-12-04 0:38 ` [PATCH v3 12/18] numa: Split the numa initialization Babu Moger
2019-12-04 0:38 ` [PATCH v3 13/18] hw/i386: Introduce apicid_from_cpu_idx in PCMachineState Babu Moger
2019-12-04 0:38 ` [PATCH v3 14/18] hw/i386: Introduce topo_ids_from_apicid handler PCMachineState Babu Moger
2019-12-04 0:38 ` [PATCH v3 15/18] hw/i386: Introduce apic_id_from_topo_ids handler in PCMachineState Babu Moger
2019-12-04 0:38 ` [PATCH v3 16/18] hw/i386: Introduce EPYC mode function handlers Babu Moger
2020-01-28 20:04 ` Eduardo Habkost
2020-01-28 21:48 ` Babu Moger
2020-01-29 16:41 ` Eduardo Habkost [this message]
2019-12-04 0:38 ` [PATCH v3 17/18] i386: Fix pkg_id offset for epyc mode Babu Moger
2019-12-04 0:39 ` [PATCH v3 18/18] tests: Update the Unit tests Babu Moger
2020-02-03 14:59 ` [PATCH v3 00/18] APIC ID fixes for AMD EPYC CPU models Igor Mammedov
2020-02-03 19:31 ` Babu Moger
2020-02-04 8:02 ` Igor Mammedov
2020-02-04 19:08 ` Babu Moger
2020-02-05 9:38 ` Igor Mammedov
2020-02-05 16:10 ` Babu Moger
2020-02-05 16:56 ` Igor Mammedov
2020-02-05 19:07 ` Babu Moger
2020-02-06 13:08 ` Igor Mammedov
2020-02-06 15:32 ` 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=20200129164154.GP18770@habkost.net \
--to=ehabkost@redhat.com \
--cc=armbru@redhat.com \
--cc=babu.moger@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.