[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineSt
From: |
Igor Mammedov |
Subject: |
Re: [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState |
Date: |
Fri, 18 Dec 2015 11:46:05 +0100 |
On Thu, 17 Dec 2015 16:09:23 -0200
Eduardo Habkost <address@hidden> wrote:
> On Wed, Dec 16, 2015 at 11:26:20PM +0100, Igor Mammedov wrote:
> > On Wed, 16 Dec 2015 17:39:02 -0200
> > Eduardo Habkost <address@hidden> wrote:
> >
> > > On Wed, Dec 16, 2015 at 05:54:25PM +0100, Igor Mammedov wrote:
> > > > On Tue, 15 Dec 2015 14:08:09 +0530
> > > > Bharata B Rao <address@hidden> wrote:
> > > >
> > > > > On Mon, Dec 14, 2015 at 03:29:49PM -0200, Eduardo Habkost wrote:
> > > > > > On Thu, Dec 10, 2015 at 11:45:37AM +0530, Bharata B Rao wrote:
> > > > > > > Storing CPU typename in MachineState lets us to create CPU
> > > > > > > threads for all architectures in uniform manner from
> > > > > > > arch-neutral code.
> > > > > > >
> > > > > > > TODO: Touching only i386 and spapr targets for now
> > > > > > >
> > > > > > > Signed-off-by: Bharata B Rao <address@hidden>
> > > > > >
> > > > > > Suggestions:
> > > > > >
> > > > > > * Name the field "cpu_base_type" to indicate it is the base CPU
> > > > > > class name, not the actual CPU class name used when creating
> > > > > > CPUs.
> > > > > > * Put it in MachineClass, as it may be useful for code that
> > > > > > runs before machine->init(), in the future.
> > > > >
> > > > > Ok.
> > > > >
> > > > > > * Maybe make it a CPUClass* field instead of a string?
> > > > >
> > > > > In the current use case, this base cpu type string is being passed
> > > > > to cpu_generic_init(const char *typename, const char *cpu_model)
> > > > > to create boot time CPUs with given typename and cpu_mode. So for
> > > > > now the string makes sense for use case.
> > > > >
> > > > > Making it CPUClass* would necessiate more changes to
> > > > > cpu_generic_init().
> > > > how about actually leaving it as "cpu_type" and putting in it
> > > > actual cpu type that could be used with device_add().
> > > >
> > > > that would get rid of keeping and passing around intermediate
> > > > cpu_model.
> > >
> > > Makes sense. We only need to save both typename and cpu_model
> > > today because cpu_generic_init() currently encapsulates three
> > > steps: CPU class lookup + CPU creation + CPU feature parsing. But
> > > we shouldn't need to redo CPU class lookup every time.
> > BTW: Eduardo do you know if QEMU could somehow provide a list of
> > supported CPU types (i.e. not cpumodels) to libvirt?
>
> Not sure I understand the question. Could you clarify what you
> mean by "supported CPU types", and what's the problem it would
> solve?
device_add TYPE, takes only type name so I'd like to kep it that way
and make sure that libvirt/user can list cpu types that hi would
be able to use with device_add/-device.
for PC they are generated from cpu_model with help of x86_cpu_type_name()
> >
> > >
> > > We could just split cpu_model once, and save the resulting
> > > CPUClass* + featurestr, instead of saving the full cpu_model
> > > string and parsing it again every time.
> > isn't featurestr as x86/sparc specific?
> >
> > Could we have field in x86_cpu_class/sparc_cpu_class for it and set it
> > when cpu_model is parsed?
> > That way generic cpu_model parser would handle only cpu names and
> > target specific overrides would handle both.
>
> I always assumed we want to have a generic CPU model + featurestr
> mechanism that could be reused by multiple architectures.
I've thought the opposite way, that we wanted to faze out featurestr
in favor of generic option parsing of generic device, i.e.
-device TYPE,option=X,...
but we would have to keep compatibility with old CLI
that supplies cpu definition via -cpu cpu_model,featurestr
so cpu_model translated into "cpu_type" field make sense for every
target but featurestr is x86/sparc specific and I'd prefer to
keep it that way and do not introduce it to other targets.
- Re: [Qemu-devel] [RFC PATCH v0 1/9] vl: Don't allow CPU toplogies with partially filled cores, (continued)
[Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState, Bharata B Rao, 2015/12/10
- Re: [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState, Eduardo Habkost, 2015/12/14
- Re: [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState, Bharata B Rao, 2015/12/15
- Re: [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState, Eduardo Habkost, 2015/12/15
- Re: [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState, Igor Mammedov, 2015/12/16
- Re: [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState, Eduardo Habkost, 2015/12/16
- Re: [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState, Igor Mammedov, 2015/12/16
- Re: [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState, Eduardo Habkost, 2015/12/17
- Re: [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState,
Igor Mammedov <=
- Re: [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState, Eduardo Habkost, 2015/12/18
- Re: [Qemu-devel] [RFC PATCH v0 2/9] cpu: Store CPU typename in MachineState, Igor Mammedov, 2015/12/18
[Qemu-devel] [RFC PATCH v0 4/9] cpu: CPU socket backend, Bharata B Rao, 2015/12/10
[Qemu-devel] [RFC PATCH v0 6/9] cpu: Introduce CPU core device, Bharata B Rao, 2015/12/10
[Qemu-devel] [RFC PATCH v0 5/9] vl: Create CPU socket backend objects, Bharata B Rao, 2015/12/10
[Qemu-devel] [RFC PATCH v0 3/9] cpu: Don't realize CPU from cpu_generic_init(), Bharata B Rao, 2015/12/10
[Qemu-devel] [RFC PATCH v0 7/9] spapr: Convert boot CPUs into CPU core device initialization, Bharata B Rao, 2015/12/10
[Qemu-devel] [RFC PATCH v0 9/9] pc: Convert boot CPUs into CPU core device initialization, Bharata B Rao, 2015/12/10
[Qemu-devel] [RFC PATCH v0 8/9] target-i386: Set apic_id during CPU initfn, Bharata B Rao, 2015/12/10