From: Igor Mammedov <imammedo@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: qemu-devel@nongnu.org, "Gleb Natapov" <gleb@redhat.com>,
"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [RFC 06/15] pc: set FW_CFG data based on APIC ID calculation
Date: Mon, 13 Aug 2012 21:52:43 +0200 [thread overview]
Message-ID: <50295B0B.5070409@redhat.com> (raw)
In-Reply-To: <1344369413-9053-7-git-send-email-ehabkost@redhat.com>
On 08/07/2012 09:56 PM, Eduardo Habkost wrote:
> This changes FW_CFG_MAX_CPUS and FW_CFG_NUMA to use apic_id_for_cpu(),
> so the NUMA table can be based on the APIC IDs, instead of CPU index
> (SeaBIOS knows nothing about CPU indexes, just APIC IDs).
>
> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
> ---
> hw/pc.c | 23 ++++++++++++++++-------
> target-i386/cpu.h | 7 +++++++
> 2 files changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/hw/pc.c b/hw/pc.c
> index 10449bd..9afb838 100644
> --- a/hw/pc.c
> +++ b/hw/pc.c
> @@ -581,6 +581,11 @@ int e820_add_entry(uint64_t address, uint64_t length, uint32_t type)
> return index;
> }
>
> +unsigned int apic_id_limit(void)
> +{
> + return apic_id_for_cpu(max_cpus - 1) + 1;
> +}
> +
> static void *bochs_bios_init(void)
> {
> void *fw_cfg;
> @@ -588,6 +593,7 @@ static void *bochs_bios_init(void)
> size_t smbios_len;
> uint64_t *numa_fw_cfg;
> int i, j;
> + unsigned int max_apic_id = apic_id_limit();
>
> register_ioport_write(0x400, 1, 2, bochs_bios_write, NULL);
> register_ioport_write(0x401, 1, 2, bochs_bios_write, NULL);
> @@ -602,7 +608,7 @@ static void *bochs_bios_init(void)
> register_ioport_write(0x503, 1, 1, bochs_bios_write, NULL);
>
> fw_cfg = fw_cfg_init(BIOS_CFG_IOPORT, BIOS_CFG_IOPORT + 1, 0, 0);
> - fw_cfg_add_i16(fw_cfg, FW_CFG_MAX_CPUS, (uint16_t)max_cpus);
> + fw_cfg_add_i16(fw_cfg, FW_CFG_MAX_CPUS, (uint16_t)max_apic_id);
FW_CFG_MAX_CPUS becoming not MAX_CPUS sounds a bit confusing, perhaps
short comment should be here to document this and why it's not? So code
reader won't make false assumptions?
> fw_cfg_add_i32(fw_cfg, FW_CFG_ID, 1);
> fw_cfg_add_i64(fw_cfg, FW_CFG_RAM_SIZE, (uint64_t)ram_size);
> fw_cfg_add_bytes(fw_cfg, FW_CFG_ACPI_TABLES, (uint8_t *)acpi_tables,
> @@ -622,21 +628,24 @@ static void *bochs_bios_init(void)
> * of nodes, one word for each VCPU->node and one word for each node to
> * hold the amount of memory.
> */
> - numa_fw_cfg = g_malloc0((1 + max_cpus + nb_numa_nodes) * 8);
> + numa_fw_cfg = g_malloc0((1 + max_apic_id + nb_numa_nodes) * 8);
> numa_fw_cfg[0] = cpu_to_le64(nb_numa_nodes);
> - for (i = 0; i < max_cpus; i++) {
> + unsigned int cpu_idx;
> + for (cpu_idx = 0; cpu_idx < max_cpus; cpu_idx++) {
> + unsigned int apic_id = apic_id_for_cpu(cpu_idx);
> + assert(apic_id < max_apic_id);
> for (j = 0; j < nb_numa_nodes; j++) {
> - if (test_bit(i, node_cpumask[j])) {
> - numa_fw_cfg[i + 1] = cpu_to_le64(j);
> + if (test_bit(cpu_idx, node_cpumask[j])) {
> + numa_fw_cfg[apic_id + 1] = cpu_to_le64(j);
> break;
> }
> }
> }
> for (i = 0; i < nb_numa_nodes; i++) {
> - numa_fw_cfg[max_cpus + 1 + i] = cpu_to_le64(node_mem[i]);
> + numa_fw_cfg[max_apic_id + 1 + i] = cpu_to_le64(node_mem[i]);
> }
> fw_cfg_add_bytes(fw_cfg, FW_CFG_NUMA, (uint8_t *)numa_fw_cfg,
> - (1 + max_cpus + nb_numa_nodes) * 8);
> + (1 + max_apic_id + nb_numa_nodes) * 8);
>
> return fw_cfg;
> }
> diff --git a/target-i386/cpu.h b/target-i386/cpu.h
> index 39ea005..257d6c7 100644
> --- a/target-i386/cpu.h
> +++ b/target-i386/cpu.h
> @@ -919,6 +919,13 @@ void host_cpuid(uint32_t function, uint32_t count,
> */
> unsigned int apic_id_for_cpu(int cpu_index);
>
> +/* Calculate limit for the APIC ID value, based on max_cpus
> + *
> + * On PC, FW_CFG_MAX_CPUS is not max_cpus, but the limit for the APIC IDs
> + * of all CPUs (so that of all CPUs APIC ID < MAX_CPUS).
> + */
> +unsigned int apic_id_limit(void);
> +
>
> /* helper.c */
> int cpu_x86_handle_mmu_fault(CPUX86State *env, target_ulong addr,
>
--
Regards,
Igor
next prev parent reply other threads:[~2012-08-13 19:52 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-07 19:56 [Qemu-devel] [RFC 00/15] attempt to fix CPU topology info on CPU APIC IDs Eduardo Habkost
2012-08-07 19:56 ` [Qemu-devel] [RFC 01/15] cpus.h: include cpu-common.h Eduardo Habkost
2012-08-13 19:06 ` Igor Mammedov
2012-08-07 19:56 ` [Qemu-devel] [RFC 02/15] hw/apic.c: rename bit functions to not conflict with bitops.h (v2) Eduardo Habkost
2012-08-13 19:08 ` Igor Mammedov
2012-08-07 19:56 ` [Qemu-devel] [RFC 03/15] kvm: set vcpu_id to APIC ID instead of CPU index Eduardo Habkost
2012-08-13 19:16 ` Igor Mammedov
2012-08-13 19:59 ` Eduardo Habkost
2012-08-07 19:56 ` [Qemu-devel] [RFC 04/15] i386: create apic_id_for_cpu() function (v2) Eduardo Habkost
2012-08-07 19:56 ` [Qemu-devel] [RFC 05/15] remove FW_CFG_MAX_CPUS from fw_cfg_init() Eduardo Habkost
2012-08-07 19:56 ` [Qemu-devel] [RFC 06/15] pc: set FW_CFG data based on APIC ID calculation Eduardo Habkost
2012-08-13 19:52 ` Igor Mammedov [this message]
2012-08-13 20:01 ` Eduardo Habkost
2012-08-07 19:56 ` [Qemu-devel] [RFC 07/15] qdev: allow qdev_prop_parse() to report errors Eduardo Habkost
2012-08-07 19:56 ` [Qemu-devel] [RFC 08/15] move global properties code to global-properties.c Eduardo Habkost
2012-08-07 19:56 ` [Qemu-devel] [RFC 09/15] isolate qdev-independent parts of qdev_prop_set_globals() Eduardo Habkost
2012-08-07 19:56 ` [Qemu-devel] [RFC 10/15] create object_prop_set_globals() Eduardo Habkost
2012-08-07 19:56 ` [Qemu-devel] [RFC 11/15] rename qdev_prop_register_global_list to qemu_globals_register_list Eduardo Habkost
2012-08-07 19:56 ` [Qemu-devel] [RFC 12/15] create qemu_global_get() function Eduardo Habkost
2012-08-07 19:56 ` [Qemu-devel] [RFC 13/15] tests: support target-specific unit tests Eduardo Habkost
2012-08-07 19:56 ` [Qemu-devel] [RFC 14/15] i386: topology & APIC ID utility functions (v2) Eduardo Habkost
2012-08-08 18:57 ` Blue Swirl
2012-08-08 19:06 ` Eduardo Habkost
2012-08-14 17:03 ` Igor Mammedov
2012-08-07 19:56 ` [Qemu-devel] [RFC 15/15] generate APIC IDs according to CPU topology (v2) Eduardo Habkost
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=50295B0B.5070409@redhat.com \
--to=imammedo@redhat.com \
--cc=afaerber@suse.de \
--cc=ehabkost@redhat.com \
--cc=gleb@redhat.com \
--cc=qemu-devel@nongnu.org \
/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.