qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 2/8] cpu: introduce possible-cpus interface


From: Igor Mammedov
Subject: Re: [Qemu-devel] [PATCH v3 2/8] cpu: introduce possible-cpus interface
Date: Wed, 24 Feb 2016 09:36:32 +0100

On Tue, 23 Feb 2016 18:38:33 -0300
Eduardo Habkost <address@hidden> 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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]