On Tue, 23 Feb 2016 18:38:33 -0300 Eduardo Habkost <ehabk...@redhat.com> wrote:
> On Tue, Feb 23, 2016 at 05:05:54PM +0100, 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/SRAT 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. > > > > This interface will also allow to help making AML > > part of CPU hotplug target independent so it could > > be reused for ARM target. > > Do you expect any non-TYPE_MACHINE class to implement this > interface? If not, why not just make it a simple MachineClass > field? Machines that don't implement the get_possible_cpus_list() > method would just have it set to NULL. I redid it with interface so that not clatter MachineClass with fields that won't be used by all(most) machines, as they don't care about hotplug. There is no other reason than that. If you think it's better to do with MachineClass hook I can quickly respin series with it. Marcel, what is your opinion on it?
