Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

[David Hildenbrand]

> I assume Igor explained it, already, and his suggestion sounds OK
> to you. But I will answer your questions to confirm that this is
> really the case:

Yes, this all sounds good to me, thanks for the additional explanation!
[...]

> 
> > 
> > d) has to work for us. Otherwise we will have to fallback to manual
> > property parsing.  
> 
> It will be affected by the globals, but I assume management code
> is not going to use add extra -cpu arguments when probing for CPU
> model information, right?

Yes, that's also what I figured out, this should not be a problem.

> 
> Users will need to be aware that -cpu is equivalent to -global,
> and will affect CPU information returned by query-cpu-definitions
> (or similar commands).
> 
> >   
> > > 
> > > If all you need is to parse properties, why can't you reuse the
> > > existing QOM/Device mechanisms to handle properties (the one used
> > > by -device and device_add), instead of the -cpu code?  
> > 
> > We can, if my given example works. And the global properties
> > don't interfere with cpus.  
> 
> They do, but only the model specified in -cpu.
> 
> >   
> > > 
> > > We need to use less of the infrastructure that exists for the
> > > legacy -cpu option (and use more of the generic QOM/Device
> > > mechanisms), not more of it.  
> > 
> > It is better to have one way of creating cpus that two.  
> 
> Unfortunately we already have two ways of creating CPUs: -cpu and
> device_add. We are trying to translate -cpu to something
> equivalent to generic mechanisms (-device and -global), so we
> have only one underlying mechanism.

Yes, understood. Sounds sane to me!
[...]

> I understand that this may be confusing, but that's because -smp
> and -cpu don't fit the QEMU device/object models. We are moving
> towards allowing CPU topologies to be created using only -device.
> 
> To do that, we are gradually translating -cpu to the generic
> mechanisms used by -device/-global, so command-line options could
> be easily converted to use the new mechanisms in the future.
> 
> Does that make sense?
> 

Absolutely!

David

Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

[Eduardo Habkost]

On Fri, Jun 03, 2016 at 08:36:21AM +0200, David Hildenbrand wrote:
> > On Thu, Jun 02, 2016 at 10:44:49PM +0200, David Hildenbrand wrote:
> > > > Current CLI option -cpu cpux,features serves as template
> > > > for all created cpus of type: cpux. However QEMU parses
> > > > "features" every time it creates a cpu instance and applies
> > > > them to it while doing parsing.
> > > > 
> > > > That doesn't work well with -device/device_add infrastructure
> > > > as it has no idea about cpu specific hooks that's used for
> > > > parsing "features".
> > > > In order to make -device/device_add utilize "-cpu features"
> > > > template convert it into a set of global properties, so that
> > > > every new CPU created will have them applied automatically.
> > > > 
> > > > That also allows to parse features only once, instread of
> > > > doing it for every CPU instance created.  
> > > 
> > > While I think this makes sense for most cases, we (s390x) are
> > > currently working on a mechanism to compare and baseline cpu models via
> > > a qmp interface, to not have to replicate CPU models in libvirt
> > > every time we do some changes.
> > > 
> > > To do that, we are creating temporary CPUs to handle the model
> > > parsing. So, with our current prototype, we rely on the mechanism
> > > to parse properties multiple time, as we are really creating
> > > different CPUs.  
> > 
> > This series only changes the code that exists for parsing the
> > -cpu option, and nothing else. Is this (the code that parses
> > -cpu) really what you need to reuse?
> 
> I was reading "every new CPU created will have them applied automatically".
> If I was having a basic understanding problem here, very good :)

Sorry, I misunderstood you:

So, you won't reuse the code for -cpu, but with global
properties, you are going to be affected even if you do a simple
object_new()/device_add. I see the problem, now.

I assume Igor explained it, already, and his suggestion sounds OK
to you. But I will answer your questions to confirm that this is
really the case:

> 
> The problematic part is when the properties are applied where the
> "changed" data is stored (class. vs. instance).
> 
> e.g. in terms of s390x: z13 includes both vx and tx
> -cpu z13,vx=off,tx=off

This will be translated to:
-global z13-s390-cpu.vx=off -global z13-s390-cpu.tx=off

> 
> Now, what would happen on
> a) device_add z13-s390-cpu // I assume vx=off, tx=off ?

Yes.

> 
> b) device_add z13-s390-cpu,vx=on // vx=on suddenly for all vcpus or one
> instance? I assume just this instance

It would affect all z13-s390-cpu instances.

> 
> c) device_add zBC12-s390-cpu // will I suddenly get a z13?
> Or a zBC12 without tx and vx? I assume the latter.

A zBC12 with the default values (not affected by -cpu).

> 
> d) object_new("z13-s390-cpu")); // will I get a clean z13 with tx and vx on?

The same as device_add z13-s390-cpu (a z13 without
tx and vx).

> 
> d) has to work for us. Otherwise we will have to fallback to manual
> property parsing.

It will be affected by the globals, but I assume management code
is not going to use add extra -cpu arguments when probing for CPU
model information, right?

Users will need to be aware that -cpu is equivalent to -global,
and will affect CPU information returned by query-cpu-definitions
(or similar commands).

> 
> > 
> > If all you need is to parse properties, why can't you reuse the
> > existing QOM/Device mechanisms to handle properties (the one used
> > by -device and device_add), instead of the -cpu code?
> 
> We can, if my given example works. And the global properties
> don't interfere with cpus.

They do, but only the model specified in -cpu.

> 
> > 
> > We need to use less of the infrastructure that exists for the
> > legacy -cpu option (and use more of the generic QOM/Device
> > mechanisms), not more of it.
> 
> It is better to have one way of creating cpus that two.

Unfortunately we already have two ways of creating CPUs: -cpu and
device_add. We are trying to translate -cpu to something
equivalent to generic mechanisms (-device and -global), so we
have only one underlying mechanism.

> 
> > 
> > 
> > > 
> > > While we could somehow change our mechanism I don't think this is
> > > the right thing to do.
> > >   
> > 
> > If reusing the existing parsing code is something you absolutely
> > need, we could split the process in two parts: 1) converting the
> > feature string to a list of property=value pairs; 2) registering
> > the property=value pairs as global properties. Then you coulde
> > reuse (1) only. But do you really need to reuse the parser for
> > the legacy -cpu option in your mechanism?
> 
> It's really not about the parser, more about the global properties.

Understood.

> 
> > 
> > > We will have to support heterogeneous cpu models (I think arm was one of
> > > the guys requesting this if I'm not mistaking) and it somehow
> > > contradicts to the general mechanism of device_add fully specifying
> > > parameters. These would 

Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

[David Hildenbrand]

> On Thu, Jun 02, 2016 at 22:44:49 +0200, David Hildenbrand wrote:
> > > Current CLI option -cpu cpux,features serves as template
> > > for all created cpus of type: cpux. However QEMU parses
> > > "features" every time it creates a cpu instance and applies
> > > them to it while doing parsing.
> > > 
> > > That doesn't work well with -device/device_add infrastructure
> > > as it has no idea about cpu specific hooks that's used for
> > > parsing "features".
> > > In order to make -device/device_add utilize "-cpu features"
> > > template convert it into a set of global properties, so that
> > > every new CPU created will have them applied automatically.
> > > 
> > > That also allows to parse features only once, instread of
> > > doing it for every CPU instance created.  
> > 
> > While I think this makes sense for most cases, we (s390x) are
> > currently working on a mechanism to compare and baseline cpu models via
> > a qmp interface, to not have to replicate CPU models in libvirt
> > every time we do some changes.  
> 
> BTW, we don't replicate any change to QEMU CPU models in libvirt. We
> merely add new CPU models that match the current QEMU definition.
> Existing CPU models are never changed. And while the CPU models are
> currently used to check compatibility with host CPU, we will stop doing
> that in the near future and our CPU models will mostly be used for
> detecting what the host CPU is.
> 
> Jirka
> 


Hi Jirka,

thanks for that info!

unfortunately we will have to perform changes to the cpu models.
On z we have various cpu features that are confidential and only
added over time, although they are around for quite some time.
And we have features that are not implemented yet by KVM and will not
be implemented in the near future.
Therefore we will be adding features to our "flexible models"
while keeping migration safe variants with base features stable.

Some day in the future, we will also have all features around :)

Another problematic thing for us is, that we really have to rely
on a host cpu model detection using KVM. The features that
are visible in user space (similar to cpuid()) don't give any
guarantees to what we are able to virtualize.

David

Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

[Jiri Denemark]

On Thu, Jun 02, 2016 at 22:44:49 +0200, David Hildenbrand wrote:
> > Current CLI option -cpu cpux,features serves as template
> > for all created cpus of type: cpux. However QEMU parses
> > "features" every time it creates a cpu instance and applies
> > them to it while doing parsing.
> > 
> > That doesn't work well with -device/device_add infrastructure
> > as it has no idea about cpu specific hooks that's used for
> > parsing "features".
> > In order to make -device/device_add utilize "-cpu features"
> > template convert it into a set of global properties, so that
> > every new CPU created will have them applied automatically.
> > 
> > That also allows to parse features only once, instread of
> > doing it for every CPU instance created.
> 
> While I think this makes sense for most cases, we (s390x) are
> currently working on a mechanism to compare and baseline cpu models via
> a qmp interface, to not have to replicate CPU models in libvirt
> every time we do some changes.

BTW, we don't replicate any change to QEMU CPU models in libvirt. We
merely add new CPU models that match the current QEMU definition.
Existing CPU models are never changed. And while the CPU models are
currently used to check compatibility with host CPU, we will stop doing
that in the near future and our CPU models will mostly be used for
detecting what the host CPU is.

Jirka

Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

[David Hildenbrand]

> > e.g. in terms of s390x: z13 includes both vx and tx
> > -cpu z13,vx=off,tx=off  
> Above -cpu template will be translated into a corresponding
> global properties template:
> 
> -global z13-s390-cpu.vx=off -global z13-s390-cpu.tx=off

This description makes it much clearer how you expect -cpu to behave. Thanks.
The important part for me was that -global applies to this cpu type only.

And our internal hierarchy should make sure that this is guaranteed. 
And good to known that it is a common schema we are following here.

> > d) object_new("z13-s390-cpu")); // will I get a clean z13 with tx and vx 
> > on?  
> nope, you'll z13 with tx and vx off
> 
> > d) has to work for us. Otherwise we will have to fallback to manual
> > property parsing.  
> could you elaborate more why do you need (d) work
> in combination with -cpu z13,vx=off,tx=off ?
> Perhaps there is another way to do what you need.

Say we started QEMU with -z13,vx=off,tx=off.
When I do a QMP query to e.g. compare two cpu models, say a temporary cpu
zBC12,tx=on and zBC13,tx=on is created. And the additional
parameters only affect these instances as I learned.

When I now compare them, the result will depend on the
way QEMU has been started. But most likely this is okay, as
we expect this interface to be used without any cpu model at all.

This then just has to be documented accordingly.

> 
> Current code uses -cpu for creating homogeneous cpus of given type
> (i.e.) as template and that's exactly what -global cpufoo,feat=x ... does.
> 
> > > If all you need is to parse properties, why can't you reuse the
> > > existing QOM/Device mechanisms to handle properties (the one used
> > > by -device and device_add), instead of the -cpu code?
> > 
> > We can, if my given example works. And the global properties
> > don't interfere with cpus.  
> if you need pure -device/device_add handling then don't use
> -cpu CPUFOO,feat=x,... template as its current semantic
> is to create all CPUs of type CPUFOO with feat=x,... applied
> > It is a bad thing as soon as they affect other devices.
> > If I did a -cpu z13,tx=off, I don't expect
> > 
> > a) a hot-plugged z13 to suddenly have tx=off  
> you should expect it though, as -cpu z13,tx=off is template
> for all z13 CPUs, it's not per instance thingy
> 
> > b) a hot-plugged zBC12 to suddenly have tx off  
> that will not have tx off unless zBC12 is inherited from z13

They don't inherit, so this should be fine.

> 
> > Won't libvirt have to specify the cpu name either way in device-add?
> > And your plan seems to be that the properties are suddenly implicit.
> > I don't see a problem with libvirt having to specify the properties
> > manually on device add.  
> libvirt could do verbose
> #1  -device CPUFOO,feat1=x -device CPUFOO,feat1=x ...
> or
> #2  -cpu CPUFOO,feat1=x -device CPUFOO -device CPUFOO ...
>   which is equivalent of generic device syntax and not use -cpu at all:
> #3  -global CPUFOO.feat1=x -device CPUFOO -device CPUFOO ...
> 
> #3 is where we are heading to by making -device/device_add available for
> CPUs. If you wish to have CPUs of the same type but with different
> features, don't use global properties for that features.
> Just like with any other device.

So this should work for us, we just have to document that -global for cpus
or -cpu should not be used when trying to work with the new QMP 
queries.

Thanks for the explanation!

David

Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

[Igor Mammedov]

On Fri, 3 Jun 2016 08:36:21 +0200
David Hildenbrand  wrote:

> > On Thu, Jun 02, 2016 at 10:44:49PM +0200, David Hildenbrand wrote:  
> > > > Current CLI option -cpu cpux,features serves as template
> > > > for all created cpus of type: cpux. However QEMU parses
> > > > "features" every time it creates a cpu instance and applies
> > > > them to it while doing parsing.
> > > > 
> > > > That doesn't work well with -device/device_add infrastructure
> > > > as it has no idea about cpu specific hooks that's used for
> > > > parsing "features".
> > > > In order to make -device/device_add utilize "-cpu features"
> > > > template convert it into a set of global properties, so that
> > > > every new CPU created will have them applied automatically.
> > > > 
> > > > That also allows to parse features only once, instread of
> > > > doing it for every CPU instance created.
> > > 
> > > While I think this makes sense for most cases, we (s390x) are
> > > currently working on a mechanism to compare and baseline cpu models via
> > > a qmp interface, to not have to replicate CPU models in libvirt
> > > every time we do some changes.
> > > 
> > > To do that, we are creating temporary CPUs to handle the model
> > > parsing. So, with our current prototype, we rely on the mechanism
> > > to parse properties multiple time, as we are really creating
> > > different CPUs. 
> > This series only changes the code that exists for parsing the
> > -cpu option, and nothing else. Is this (the code that parses
> > -cpu) really what you need to reuse?  
> 
> I was reading "every new CPU created will have them applied automatically".
> If I was having a basic understanding problem here, very good :)
I should rephrase it to "every new CPU of given cpu type"

> The problematic part is when the properties are applied where the
> "changed" data is stored (class. vs. instance).
> 
> e.g. in terms of s390x: z13 includes both vx and tx
> -cpu z13,vx=off,tx=off
Above -cpu template will be translated into a corresponding
global properties template:

-global z13-s390-cpu.vx=off -global z13-s390-cpu.tx=off


> Now, what would happen on
> a) device_add z13-s390-cpu // I assume vx=off, tx=off ?
as with current -cpu + manual cpu_model parsing per instance,
you'll get above globals applied by the time object_new("z13-s390-cpu"))
is complete.
 
> b) device_add z13-s390-cpu,vx=on // vx=on suddenly for all vcpus or one
> instance? I assume just this instance
yes, You'll get vx=on for just this instance as it's not a global property
and it's applied after object_new() by -device/device_add
 
> c) device_add zBC12-s390-cpu // will I suddenly get a z13?
> Or a zBC12 without tx and vx? I assume the latter.
that depends on class hierarchy,
if zBC12 is inherited from z13 you'll get global properties of z13 applied.
if z13 is not parent of zBC12 then z13 global properties
are not applied to zBC12.
 
Look at qdev_prop_set_globals() and how it's used.

> d) object_new("z13-s390-cpu")); // will I get a clean z13 with tx and vx on?
nope, you'll z13 with tx and vx off

> d) has to work for us. Otherwise we will have to fallback to manual
> property parsing.
could you elaborate more why do you need (d) work
in combination with -cpu z13,vx=off,tx=off ?
Perhaps there is another way to do what you need.

Current code uses -cpu for creating homogeneous cpus of given type
(i.e.) as template and that's exactly what -global cpufoo,feat=x ... does.

> > If all you need is to parse properties, why can't you reuse the
> > existing QOM/Device mechanisms to handle properties (the one used
> > by -device and device_add), instead of the -cpu code?  
> 
> We can, if my given example works. And the global properties
> don't interfere with cpus.
if you need pure -device/device_add handling then don't use
-cpu CPUFOO,feat=x,... template as its current semantic
is to create all CPUs of type CPUFOO with feat=x,... applied

or more exactly do not use feat... part of it if you don't need
global properties.

> 
> > 
> > We need to use less of the infrastructure that exists for the
> > legacy -cpu option (and use more of the generic QOM/Device
> > mechanisms), not more of it.  
> 
> It is better to have one way of creating cpus that two.
yep, and that's where we heading to, first by making CPU a Device
and then switching to generic -device/device_add model, so use one or
another, -cpu is kept there for compat reasons and some day
we probably could kill it.

> 
> > 
> >   
> > > 
> > > While we could somehow change our mechanism I don't think this is
> > > the right thing to do.
> > > 
> > 
> > If reusing the existing parsing code is something you absolutely
> > need, we could split the process in two parts: 1) converting the
> > feature string to a list of property=value pairs; 2) registering
> > the property=value pairs as global properties. Then you coulde
> > reuse (1) only. But do you really need to reuse the parser for
> > the legacy -cpu option in your 

Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

[David Hildenbrand]

> On Thu, Jun 02, 2016 at 10:44:49PM +0200, David Hildenbrand wrote:
> > > Current CLI option -cpu cpux,features serves as template
> > > for all created cpus of type: cpux. However QEMU parses
> > > "features" every time it creates a cpu instance and applies
> > > them to it while doing parsing.
> > > 
> > > That doesn't work well with -device/device_add infrastructure
> > > as it has no idea about cpu specific hooks that's used for
> > > parsing "features".
> > > In order to make -device/device_add utilize "-cpu features"
> > > template convert it into a set of global properties, so that
> > > every new CPU created will have them applied automatically.
> > > 
> > > That also allows to parse features only once, instread of
> > > doing it for every CPU instance created.  
> > 
> > While I think this makes sense for most cases, we (s390x) are
> > currently working on a mechanism to compare and baseline cpu models via
> > a qmp interface, to not have to replicate CPU models in libvirt
> > every time we do some changes.
> > 
> > To do that, we are creating temporary CPUs to handle the model
> > parsing. So, with our current prototype, we rely on the mechanism
> > to parse properties multiple time, as we are really creating
> > different CPUs.  
> 
> This series only changes the code that exists for parsing the
> -cpu option, and nothing else. Is this (the code that parses
> -cpu) really what you need to reuse?

I was reading "every new CPU created will have them applied automatically".
If I was having a basic understanding problem here, very good :)

The problematic part is when the properties are applied where the
"changed" data is stored (class. vs. instance).

e.g. in terms of s390x: z13 includes both vx and tx
-cpu z13,vx=off,tx=off

Now, what would happen on
a) device_add z13-s390-cpu // I assume vx=off, tx=off ?

b) device_add z13-s390-cpu,vx=on // vx=on suddenly for all vcpus or one
instance? I assume just this instance

c) device_add zBC12-s390-cpu // will I suddenly get a z13?
Or a zBC12 without tx and vx? I assume the latter.

d) object_new("z13-s390-cpu")); // will I get a clean z13 with tx and vx on?

d) has to work for us. Otherwise we will have to fallback to manual
property parsing.

> 
> If all you need is to parse properties, why can't you reuse the
> existing QOM/Device mechanisms to handle properties (the one used
> by -device and device_add), instead of the -cpu code?

We can, if my given example works. And the global properties
don't interfere with cpus.

> 
> We need to use less of the infrastructure that exists for the
> legacy -cpu option (and use more of the generic QOM/Device
> mechanisms), not more of it.

It is better to have one way of creating cpus that two.

> 
> 
> > 
> > While we could somehow change our mechanism I don't think this is
> > the right thing to do.
> >   
> 
> If reusing the existing parsing code is something you absolutely
> need, we could split the process in two parts: 1) converting the
> feature string to a list of property=value pairs; 2) registering
> the property=value pairs as global properties. Then you coulde
> reuse (1) only. But do you really need to reuse the parser for
> the legacy -cpu option in your mechanism?

It's really not about the parser, more about the global properties.

> 
> > We will have to support heterogeneous cpu models (I think arm was one of
> > the guys requesting this if I'm not mistaking) and it somehow
> > contradicts to the general mechanism of device_add fully specifying
> > parameters. These would now be implicit parameters.  
> 
> The -cpu interface really does contradict the general mechanism
> of device_add. This whole series is about translating the
> handling of -cpu to a more generic mechanism (-global), to allow
> us to deprecate -cpu in the future. Why is that a bad thing?

It is a bad thing as soon as they affect other devices.
If I did a -cpu z13,tx=off, I don't expect

a) a hot-plugged z13 to suddenly have tx=off
b) a hot-plugged zBC12 to suddenly have tx off

Won't libvirt have to specify the cpu name either way in device-add?
And your plan seems to be that the properties are suddenly implicit.
I don't see a problem with libvirt having to specify the properties
manually on device add.

I agree, cleaning up the parsing function indeed makes sense.

David

Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

[Eduardo Habkost]

On Thu, Jun 02, 2016 at 10:44:49PM +0200, David Hildenbrand wrote:
> > Current CLI option -cpu cpux,features serves as template
> > for all created cpus of type: cpux. However QEMU parses
> > "features" every time it creates a cpu instance and applies
> > them to it while doing parsing.
> > 
> > That doesn't work well with -device/device_add infrastructure
> > as it has no idea about cpu specific hooks that's used for
> > parsing "features".
> > In order to make -device/device_add utilize "-cpu features"
> > template convert it into a set of global properties, so that
> > every new CPU created will have them applied automatically.
> > 
> > That also allows to parse features only once, instread of
> > doing it for every CPU instance created.
> 
> While I think this makes sense for most cases, we (s390x) are
> currently working on a mechanism to compare and baseline cpu models via
> a qmp interface, to not have to replicate CPU models in libvirt
> every time we do some changes.
> 
> To do that, we are creating temporary CPUs to handle the model
> parsing. So, with our current prototype, we rely on the mechanism
> to parse properties multiple time, as we are really creating
> different CPUs.

This series only changes the code that exists for parsing the
-cpu option, and nothing else. Is this (the code that parses
-cpu) really what you need to reuse?

If all you need is to parse properties, why can't you reuse the
existing QOM/Device mechanisms to handle properties (the one used
by -device and device_add), instead of the -cpu code?

We need to use less of the infrastructure that exists for the
legacy -cpu option (and use more of the generic QOM/Device
mechanisms), not more of it.


> 
> While we could somehow change our mechanism I don't think this is
> the right thing to do.
> 

If reusing the existing parsing code is something you absolutely
need, we could split the process in two parts: 1) converting the
feature string to a list of property=value pairs; 2) registering
the property=value pairs as global properties. Then you coulde
reuse (1) only. But do you really need to reuse the parser for
the legacy -cpu option in your mechanism?

> We will have to support heterogeneous cpu models (I think arm was one of
> the guys requesting this if I'm not mistaking) and it somehow
> contradicts to the general mechanism of device_add fully specifying
> parameters. These would now be implicit parameters.

The -cpu interface really does contradict the general mechanism
of device_add. This whole series is about translating the
handling of -cpu to a more generic mechanism (-global), to allow
us to deprecate -cpu in the future. Why is that a bad thing?

> 
> Would it be possible to do this for x86 only? Or find another way
> to handle the "create just another ordinary CPU we already have"?

Can you clarify what "create just another ordinary CPU we already
have" mean? If you are talking about creating another CPU using
what's on -cpu, nothing changes. If you are talking about
creating another CPU with different options, I suggest not
reusing the code that was written for -cpu.

-- 
Eduardo

Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

[David Hildenbrand]

> Current CLI option -cpu cpux,features serves as template
> for all created cpus of type: cpux. However QEMU parses
> "features" every time it creates a cpu instance and applies
> them to it while doing parsing.
> 
> That doesn't work well with -device/device_add infrastructure
> as it has no idea about cpu specific hooks that's used for
> parsing "features".
> In order to make -device/device_add utilize "-cpu features"
> template convert it into a set of global properties, so that
> every new CPU created will have them applied automatically.
> 
> That also allows to parse features only once, instread of
> doing it for every CPU instance created.

While I think this makes sense for most cases, we (s390x) are
currently working on a mechanism to compare and baseline cpu models via
a qmp interface, to not have to replicate CPU models in libvirt
every time we do some changes.

To do that, we are creating temporary CPUs to handle the model
parsing. So, with our current prototype, we rely on the mechanism
to parse properties multiple time, as we are really creating
different CPUs.

While we could somehow change our mechanism I don't think this is
the right thing to do.

We will have to support heterogeneous cpu models (I think arm was one of
the guys requesting this if I'm not mistaking) and it somehow
contradicts to the general mechanism of device_add fully specifying
parameters. These would now be implicit parameters.

Would it be possible to do this for x86 only? Or find another way
to handle the "create just another ordinary CPU we already have"?

David

Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

[Eduardo Habkost]

On Wed, Jun 01, 2016 at 07:21:00PM +0100, Peter Maydell wrote:
> On 1 June 2016 at 17:37, Igor Mammedov  wrote:
> > Current CLI option -cpu cpux,features serves as template
> > for all created cpus of type: cpux. However QEMU parses
> > "features" every time it creates a cpu instance and applies
> > them to it while doing parsing.
> >
> > That doesn't work well with -device/device_add infrastructure
> > as it has no idea about cpu specific hooks that's used for
> > parsing "features".
> > In order to make -device/device_add utilize "-cpu features"
> > template convert it into a set of global properties, so that
> > every new CPU created will have them applied automatically.
> 
> Is there a plan for supporting heterogenous CPU setups?
> (We don't really do those very well at the moment, but
> we might in future. The closest we come today is the
> zynqmp SoC which has Cortex-R5s and A53s in it.)

I am not aware of any specific plan, but this series gets us
closer to eventually replacing -cpu (which doesn't allow
heterogenous CPU setups) with simple -device/-global combinations
(which would be more flexible).

-- 
Eduardo

Re: [Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

[Peter Maydell]

On 1 June 2016 at 17:37, Igor Mammedov  wrote:
> Current CLI option -cpu cpux,features serves as template
> for all created cpus of type: cpux. However QEMU parses
> "features" every time it creates a cpu instance and applies
> them to it while doing parsing.
>
> That doesn't work well with -device/device_add infrastructure
> as it has no idea about cpu specific hooks that's used for
> parsing "features".
> In order to make -device/device_add utilize "-cpu features"
> template convert it into a set of global properties, so that
> every new CPU created will have them applied automatically.

Is there a plan for supporting heterogenous CPU setups?
(We don't really do those very well at the moment, but
we might in future. The closest we come today is the
zynqmp SoC which has Cortex-R5s and A53s in it.)

thanks
-- PMM

[Qemu-devel] [PATCH RFC 0/8] cpus: make "-cpu cpux, features" global properties

[Igor Mammedov]

Current CLI option -cpu cpux,features serves as template
for all created cpus of type: cpux. However QEMU parses
"features" every time it creates a cpu instance and applies
them to it while doing parsing.

That doesn't work well with -device/device_add infrastructure
as it has no idea about cpu specific hooks that's used for
parsing "features".
In order to make -device/device_add utilize "-cpu features"
template convert it into a set of global properties, so that
every new CPU created will have them applied automatically.

That also allows to parse features only once, instread of
doing it for every CPU instance created.


Igor Mammedov (8):
  target-i386: cpu: move features logic that requires CPUState to
realize time
  target-i386: cpu: move xcc->kvm_required check to reaize time
  target-i386: cpu: use cpu_generic_init() in cpu_x86_init()
  target-i386: cpu: consolidate calls of object_property_parse() in
x86_cpu_parse_featurestr
  target-sparc: cpu: use sparc_cpu_parse_features() directly
  cpu: use CPUClass->parse_features() as convertor to global properties
  arm: virt: parse cpu_model only once
  pc: parse cpu features only once

 hw/arm/virt.c  |  41 +++---
 hw/i386/pc.c   |  37 +
 include/qom/cpu.h  |   2 +-
 qom/cpu.c  |  29 +-
 target-i386/cpu.c  | 155 +++--
 target-i386/cpu.h  |   1 -
 target-sparc/cpu.c |   7 +--
 7 files changed, 125 insertions(+), 147 deletions(-)

-- 
1.8.3.1