qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: pbonzini@redhat.com, qemu-devel@nongnu.org,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/9] machine: introduce MachineClass.possible_cpu_arch_ids() hook
Date: Fri, 5 Feb 2016 15:49:56 +0100	[thread overview]
Message-ID: <20160205154956.5ebd706c@nial.brq.redhat.com> (raw)
In-Reply-To: <20160205141358.GP26314@thinpad.lan.raisama.net>

On Fri, 5 Feb 2016 12:13:58 -0200
Eduardo Habkost <ehabkost@redhat.com> wrote:

> On Thu, Feb 04, 2016 at 02:36:59PM +0100, Igor Mammedov wrote:
> > On Thu, 4 Feb 2016 14:18:10 +0200
> > Marcel Apfelbaum <marcel.apfelbaum@gmail.com> wrote:
> >   
> > > On 02/04/2016 01:47 PM, Igor Mammedov wrote:  
> > > > on x86 currently range 0..max_cpus is used to generate
> > > > architecture-dependent CPU ID (APIC Id) for each present
> > > > and possible CPUs. However architecture-dependent CPU IDs
> > > > list could be sparse and code that needs to enumerate
> > > > all IDs (ACPI) ended up doing guess work enumerating all
> > > > possible and impossible IDs up to
> > > >    apic_id_limit = x86_cpu_apic_id_from_index(max_cpus).
> > > >
> > > > That leads to creation of MADT entries and Processor
> > > > objects in ACPI tables for not possible CPUs.
> > > > Fix it by allowing board specify a concrete list of
> > > > CPU IDs accourding its own rules (which for x86 depends
> > > > on topology). So that code that needs this list could
> > > > request it from board instead of trying to figure out
> > > > what IDs are correct on its own.
> > > >
> > > > Signed-off-by: Igor Mammedov <imammedo@redhat.com>
> > > > ---
> > > >   hw/i386/pc.c        | 16 ++++++++++++++++
> > > >   include/hw/boards.h | 18 ++++++++++++++++++
> > > >   2 files changed, 34 insertions(+)
> > > >
> > > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > > > index d72246d..2fd8fc8 100644
> > > > --- a/hw/i386/pc.c
> > > > +++ b/hw/i386/pc.c
> > > > @@ -1946,6 +1946,21 @@ static unsigned pc_cpu_index_to_socket_id(unsigned cpu_index)
> > > >       return topo.pkg_id;
> > > >   }
> > > >
> > > > +static GArray *pc_possible_cpu_arch_ids(void)
> > > > +{
> > > > +    int i;
> > > > +    GArray *list = g_array_new (FALSE, FALSE, sizeof (CPUArchId));
> > > > +
> > > > +    for (i = 0; i < max_cpus; i++) {
> > > > +        CPUArchId val;
> > > > +
> > > > +        val.arch_id = x86_cpu_apic_id_from_index(i);
> > > > +        val.cpu = qemu_get_cpu_by_arch_id(val.arch_id);
> > > > +        g_array_append_val(list, val);
> > > > +    }
> > > > +    return list;
> > > > +}
> > > > +
> > > >   static void pc_machine_class_init(ObjectClass *oc, void *data)
> > > >   {
> > > >       MachineClass *mc = MACHINE_CLASS(oc);
> > > > @@ -1968,6 +1983,7 @@ static void pc_machine_class_init(ObjectClass *oc, void *data)
> > > >       pcmc->save_tsc_khz = true;
> > > >       mc->get_hotplug_handler = pc_get_hotpug_handler;
> > > >       mc->cpu_index_to_socket_id = pc_cpu_index_to_socket_id;
> > > > +    mc->possible_cpu_arch_ids = pc_possible_cpu_arch_ids;
> > > >       mc->default_boot_order = "cad";
> > > >       mc->hot_add_cpu = pc_hot_add_cpu;
> > > >       mc->max_cpus = 255;
> > > > diff --git a/include/hw/boards.h b/include/hw/boards.h
> > > > index 0f30959..bd85f46 100644
> > > > --- a/include/hw/boards.h
> > > > +++ b/include/hw/boards.h
> > > > @@ -8,6 +8,7 @@
> > > >   #include "sysemu/accel.h"
> > > >   #include "hw/qdev.h"
> > > >   #include "qom/object.h"
> > > > +#include "qom/cpu.h"
> > > >
> > > >   void memory_region_allocate_system_memory(MemoryRegion *mr, Object *owner,
> > > >                                             const char *name,
> > > > @@ -42,6 +43,16 @@ bool machine_dump_guest_core(MachineState *machine);
> > > >   bool machine_mem_merge(MachineState *machine);
> > > >
> > > >   /**
> > > > + * CPUArchId:
> > > > + * @arch_id - architecture-dependent CPU ID of present or possible CPU
> > > > + * @cpu - pointer to corresponding CPU object ii it's present on NULL otherwise
> > > > + */
> > > > +typedef struct {
> > > > +    uint64_t arch_id;
> > > > +    struct CPUState *cpu;
> > > > +} CPUArchId;
> > > > +
> > > > +/**
> > > >    * MachineClass:
> > > >    * @get_hotplug_handler: this function is called during bus-less
> > > >    *    device hotplug. If defined it returns pointer to an instance
> > > > @@ -57,6 +68,10 @@ bool machine_mem_merge(MachineState *machine);
> > > >    *    Set only by old machines because they need to keep
> > > >    *    compatibility on code that exposed QEMU_VERSION to guests in
> > > >    *    the past (and now use qemu_hw_version()).
> > > > + * @possible_cpu_arch_ids:
> > > > + *    Returns an array of @CPUArchId architecture-dependent CPU IDs
> > > > + *    which includes CPU IDs for present and possible to hotplug CPUs.
> > > > + *    Caller is responsible for freeing returned list.
> > > >    */
> > > >   struct MachineClass {
> > > >       /*< private >*/
> > > > @@ -99,8 +114,11 @@ struct MachineClass {
> > > >       HotplugHandler *(*get_hotplug_handler)(MachineState *machine,
> > > >                                              DeviceState *dev);
> > > >       unsigned (*cpu_index_to_socket_id)(unsigned cpu_index);
> > > > +    GArray *(*possible_cpu_arch_ids)(void);    
> > > 
> > > Hi Igor,
> > > 
> > > Can't this be a GArray filled in at machine init time instead of a method?
> > > Just wondering.  
> > Then it wouldn't get CPU present status as there is no CPUs at that time.
> > It would also require refatoring of vl.c as machine_init() happens
> > before -smp is parsed.  
> 
> I believe Marcel meant MachineClass::init() and related code
> (machine initialization), not machine_init() (machine type
> registration).
> 
> That said, calculating it only when actually needed sounds better
> to me. One less data field to worry about when we change ordering
> in the machine initialization code.
yep, it's dynamic information so it's better to calculate it
on demand.
I'll repsin series rebased on top of your guest info removal,
once travis.build is complete.



> 

  reply	other threads:[~2016-02-05 14:50 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-04 11:47 [Qemu-devel] [PATCH 0/9] pc: do not create invalid MADT.LAPIC/Processor entries Igor Mammedov
2016-02-04 11:47 ` [Qemu-devel] [PATCH 2/9] machine: introduce MachineClass.possible_cpu_arch_ids() hook Igor Mammedov
2016-02-04 12:18   ` Marcel Apfelbaum
2016-02-04 13:36     ` Igor Mammedov
2016-02-05 14:13       ` Eduardo Habkost
2016-02-05 14:49         ` Igor Mammedov [this message]
2016-02-05 15:04   ` Eduardo Habkost
2016-02-05 15:39     ` Igor Mammedov
2016-02-05 15:50       ` Eduardo Habkost
2016-02-05 16:29         ` Igor Mammedov
2016-02-04 11:47 ` [Qemu-devel] [PATCH 3/9] pc: acpi: cleanup qdev_get_machine() calls Igor Mammedov
2016-02-04 12:21   ` Marcel Apfelbaum
2016-02-04 11:47 ` [Qemu-devel] [PATCH 4/9] pc: acpi: SRAT: create only valid processor lapic entries Igor Mammedov
2016-02-05 15:07   ` Eduardo Habkost
2016-02-04 11:47 ` [Qemu-devel] [PATCH 5/9] pc: acpi: create Processor and Notify objects only for valid lapics Igor Mammedov
2016-02-05 15:17   ` Eduardo Habkost
2016-02-05 15:43     ` Igor Mammedov
2016-02-04 11:47 ` [Qemu-devel] [PATCH 6/9] pc: acpi: create MADT.lapic entries " Igor Mammedov
2016-02-05 15:28   ` Eduardo Habkost
2016-02-05 16:14     ` Igor Mammedov
2016-02-11 16:11       ` Eduardo Habkost
2016-02-12 10:04         ` Igor Mammedov
2016-02-04 11:47 ` [Qemu-devel] [PATCH 7/9] pc: acpi: drop not needed intermediate bitmap cpu->found_cpus Igor Mammedov
2016-02-05 15:39   ` Eduardo Habkost
2016-02-05 16:19     ` Igor Mammedov
2016-02-05 16:44       ` Igor Mammedov
2016-02-11 15:59         ` Eduardo Habkost
2016-02-12 10:05           ` Igor Mammedov
2016-02-04 11:47 ` [Qemu-devel] [PATCH 8/9] pc: move apic_id_limit to PCMachineState Igor Mammedov
     [not found]   ` <56B348BA.40502@gmail.com>
2016-02-04 17:08     ` Igor Mammedov
2016-02-04 18:18       ` Michael S. Tsirkin
2016-02-04 18:24         ` Igor Mammedov
2016-02-04 11:47 ` [Qemu-devel] [PATCH 9/9] pc: acpi: clarify why possible LAPIC entries must be present in MADT Igor Mammedov
2016-02-05 15:39   ` Eduardo Habkost
2016-02-04 11:49 ` [Qemu-devel] [PATCH 1/9] cpu: rename cpu_exists() to qemu_get_cpu_by_arch_id() Igor Mammedov
2016-02-05 14:20   ` 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=20160205154956.5ebd706c@nial.brq.redhat.com \
    --to=imammedo@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@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 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).