RE: [PATCH v2 1/5] hw: Add sockets_specified field in CpuTopology

[Anup Patel]

> -----Original Message-----
> From: Daniel P. Berrangé <address@hidden>
> Sent: 27 May 2020 16:12
> To: Anup Patel <address@hidden>
> Cc: Peter Maydell <address@hidden>; address@hidden;
> Eduardo Habkost <address@hidden>; Sagar Karandikar
> <address@hidden>; Anup Patel <address@hidden>; qemu-
> address@hidden; Atish Patra <address@hidden>; Alistair Francis
> <address@hidden>; Palmer Dabbelt <address@hidden>
> Subject: Re: [PATCH v2 1/5] hw: Add sockets_specified field in CpuTopology
> 
> On Wed, May 27, 2020 at 10:01:21AM +0000, Anup Patel wrote:
> >
> >
> > > -----Original Message-----
> > > From: Daniel P. Berrangé <address@hidden>
> > > Sent: 27 May 2020 15:21
> > > To: Anup Patel <address@hidden>
> > > Cc: Eduardo Habkost <address@hidden>; Marcel Apfelbaum
> > > <address@hidden>; Peter Maydell
> > > <address@hidden>; Palmer Dabbelt <address@hidden>;
> > > Alistair Francis <address@hidden>; Sagar Karandikar
> > > <address@hidden>; Atish Patra <address@hidden>;
> > > address@hidden; qemu- address@hidden; Anup Patel
> > > <address@hidden>
> > > Subject: Re: [PATCH v2 1/5] hw: Add sockets_specified field in
> > > CpuTopology
> > >
> > > On Wed, May 27, 2020 at 09:48:39AM +0000, Anup Patel wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Daniel P. Berrangé <address@hidden>
> > > > > Sent: 27 May 2020 14:16
> > > > > To: Anup Patel <address@hidden>
> > > > > Cc: Eduardo Habkost <address@hidden>; Marcel Apfelbaum
> > > > > <address@hidden>; Peter Maydell
> > > > > <address@hidden>; Palmer Dabbelt <address@hidden>;
> > > > > Alistair Francis <address@hidden>; Sagar Karandikar
> > > > > <address@hidden>; Atish Patra <address@hidden>;
> > > > > address@hidden; qemu- address@hidden; Anup Patel
> > > > > <address@hidden>
> > > > > Subject: Re: [PATCH v2 1/5] hw: Add sockets_specified field in
> > > > > CpuTopology
> > > > >
> > > > > On Wed, May 27, 2020 at 11:12:22AM +0530, Anup Patel wrote:
> > > > > > When "sockets" sub-option of "-smp" option is not specified,
> > > > > > the
> > > > > > smp_parse() function will assume one CPU per-socket and set
> > > > > > the number of sockets equal to number of CPUs.
> > > > > >
> > > > > > This is counter-intuitive and we should allow machine
> > > > > > emulation to decide default number of sockets when "sockets"
> > > > > > sub-option is not specified.
> > > > >
> > > > > I don't agree with this.  Having the semantics of the -smp
> > > > > option be the same across all targets/machines *is* intuitive.
> > > > > Changing semantics of -smp per- machine will create a worse
> > > > > experiance for people configuring QEMU as the configuration will
> > > > > mean different things
> > > depending on the machine choce.
> > > >
> > > > Okay then why don't we default to sockets=1 in smp_parse() when
> "sockets"
> > > > sub-options is not specified ?? This will make it uniform across 
> > > > machines.
> > > >
> > > > Is there a reason to by default have sockets=max_cpus ??
> > >
> > > IIUC both of these questions are due to backwards compatibility with
> > > pre- existing QEMU versions.
> >
> > I see that hw/x86/pc.c implements it's own smp_parse() callback.
> > Can we take that route ??
> >
> > We need to have sockets=1 by default for RISC-V machines because each
> > socket has it's own interrupt controller and other peripherals.
> 
> I guess the fact that smp_parse() exists as a callback pretty much says that
> allowing machine type overrides of default semantics is permitted. So yeah,
> using a smp_parse callback seems reasonable.

Thanks Danie, I will drop this patch and send v3 with different approach.

Regards,
Anup