[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 06/11] target-i386: add socket/core/thread prope
From: |
Igor Mammedov |
Subject: |
Re: [Qemu-devel] [PATCH 06/11] target-i386: add socket/core/thread properties to X86CPU |
Date: |
Thu, 23 Jun 2016 22:46:36 +0200 |
On Thu, 23 Jun 2016 17:18:46 -0300
Eduardo Habkost <address@hidden> wrote:
> On Thu, Jun 23, 2016 at 09:18:38PM +0200, Igor Mammedov wrote:
> > On Thu, 23 Jun 2016 14:44:53 -0300
> > Eduardo Habkost <address@hidden> wrote:
> >
> > > On Thu, Jun 23, 2016 at 04:54:24PM +0200, Igor Mammedov wrote:
> > > > these properties will be used by as address where to plug
> > > > CPU with help -device/device_add commands.
> > > >
> > > > Signed-off-by: Igor Mammedov <address@hidden>
> > > > ---
> > > > hw/i386/pc.c | 12 ++++++++++++
> > > > target-i386/cpu.c | 3 +++
> > > > target-i386/cpu.h | 4 ++++
> > > > 3 files changed, 19 insertions(+)
> > > >
> > > > diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> > > > index 6ba6343..87352ae 100644
> > > > --- a/hw/i386/pc.c
> > > > +++ b/hw/i386/pc.c
> > > > @@ -1775,6 +1775,18 @@ static void
> > > > pc_cpu_pre_plug(HotplugHandler *hotplug_dev, cpu->apic_id);
> > > > return;
> > > > }
> > > > +
> > > > + /* set 'address' properties socket/core/thread for initial
> > > > and cpu-add
> > > > + * added CPUs so that query_hotpluggable_cpus would show
> > > > correct values
> > > > + */
> > > > + if (cpu->thread == -1 || cpu->core == -1 || cpu->socket ==
> > > > -1) {
> > > > + X86CPUTopoInfo topo;
> > > > +
> > > > + x86_topo_ids_from_apicid(cpu->apic_id, smp_cores,
> > > > smp_threads, &topo);
> > > > + cpu->thread = topo.smt_id;
> > > > + cpu->core = topo.core_id;
> > > > + cpu->socket = topo.pkg_id;
> > > > + }
> > >
> > > What if both apic-id and socket/core/thread are set?
> > they shouldn't since query_hotpluggable_cpus doesn't have apic_id
> > attribute so apic_id isn't supposed to be on user provided,
> > but of cause user could add it manually on device_add command to
> > create confusion, in that case apic_id would take precedence and
> > socket/core/thread ignored.
>
> I would like to reject obviously invalid input instead of having
> unclear precedence rules.
ok
> >
> > >
> > > I suggest validating the properties, and setting them in case
> > > they are not set:
> > >
> > > x86_topo_ids_from_apicid(cpu->apic_id, smp_cores, smp_threads,
> > > &topo);
> > >
> > > if (cpu->socket != -1 && cpu->socket != topo.socket_id) {
> > > error_setg(errp, "CPU socket ID mismatch: ...");
> > > return;
> > > }
> > > cpu->socket = topo.socket_id;
> > >
> > > if (cpu->core != -1 && cpu->core != topo.core_id) {
> > > error_setg(errp, "CPU core ID mismatch: ...");
> > > return;
> > > }
> > > cpu->core = topo.core_id;
> > >
> > > if (cpu->thread != -1 && cpu->thread != topo.smt_id) {
> > > error_setg(errp, "CPU thread ID mismatch: ...");
> > > return;
> > > }
> > > cpu->thread = topo.smt_id;
> > >
> > > We could do that inside x86_cpu_realizefn(), so that
> > > socket/core/thread would be always set in all CPUs.
> > all CPUs pass through pc_cpu_pre_plug() before cpu.relizefn()
> > so I'd rather do it here at board level responsible for
> > setting apic_id or socket/core/thread info is not set.
>
> Then *-user will be inconsistent, and will always have invalid
> values in socket/core/thread. If one day we add any logic using
> the socket/core/thread properties in cpu.c, it will break on
> *-user.
>
> All those properties are X86CPU properties, meaning they are
> input to the X86CPU code. I don't see why we should move logic
> related to them outside cpu.c unless really necessary.
>
> (The apic-id calculation at patch 07/11, for example, is more
> difficult to move to cpu.c, because the PC code needs the APIC ID
> before calling realize. We could move it to the apic-id getter,
> but I dislike having magic getter/setters and like that you made
> it a static property.)
set of socket/core/thread is a synonym for apic_id and it's board that
manages and knows valid values for them. Putting above snippet into
cpu.relizefn() would make CPU access globals smp_cores, smp_threads
which are essentially machine_state and Drew working on moving them
there and eliminating globals. So suddenly CPU would need to poke into
machine object, and we return to the same state wrt *-user only with
hack in cpu.c.
I'd worry about -smp and *-user when it comes into that target as it
will probably need apic_id and maybe socket/core/thread as well.
- [Qemu-devel] [PATCH 07/11] pc: set APIC ID based on socket/core/thread ids if it's not been set yet, (continued)
[Qemu-devel] [PATCH 05/11] target-i386: cpu: replace custom apic-id setter/getter with static property, Igor Mammedov, 2016/06/23
[Qemu-devel] [PATCH 06/11] target-i386: add socket/core/thread properties to X86CPU, Igor Mammedov, 2016/06/23
[Qemu-devel] [PATCH 08/11] pc: implement query-hotpluggable-cpus callback, Igor Mammedov, 2016/06/23
[Qemu-devel] [PATCH 09/11] pc: register created initial and hotpluged CPUs in one place pc_cpu_plug(), Igor Mammedov, 2016/06/23
[Qemu-devel] [PATCH 10/11] pc: delay setting number of boot CPUs to machine_done time, Igor Mammedov, 2016/06/23
[Qemu-devel] [PATCH 11/11] pc: cpu: allow device_add to be used with x86 cpu, Igor Mammedov, 2016/06/23