Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-22 Thread Igor Mammedov
On Fri, 17 Feb 2017 19:56:32 +0100 Igor Mammedov wrote: > Some callers call CPUClass->parse_features manually to convert > '-cpu cpufoo,featurestr' string to cpu type and featurestr > into a set of global properties. And theni do controlled > cpu creation with setting

Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-21 Thread Peter Maydell
On 21 February 2017 at 18:28, Eduardo Habkost wrote: > Peter, do you think a wrapper for parse_features + object_new() > would still be necessary to avoid too much code duplication on > arm boards in 2.9, or can we live without it until we apply > Igor's series (probaly after

Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-21 Thread Eduardo Habkost
On Tue, Feb 21, 2017 at 05:59:53PM +, Peter Maydell wrote: > On 21 February 2017 at 16:18, Paolo Bonzini wrote: > > On 21/02/2017 14:57, Peter Maydell wrote: > >>> -global is a qdev thing. > >> ...which reminds me to ask: is there any hope for unifying > >> our properties

Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-21 Thread Eduardo Habkost
On Fri, Feb 17, 2017 at 07:56:32PM +0100, Igor Mammedov wrote: > > Some callers call CPUClass->parse_features manually to convert > '-cpu cpufoo,featurestr' string to cpu type and featurestr > into a set of global properties. And theni do controlled > cpu creation with setting properties and

Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-21 Thread Eduardo Habkost
On Tue, Feb 21, 2017 at 04:48:49PM +0100, Markus Armbruster wrote: > Peter Maydell writes: > > > On 21 February 2017 at 13:56, Markus Armbruster wrote: > >> -global is a qdev thing. > > > > ...which reminds me to ask: is there any hope for unifying >

Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-21 Thread Peter Maydell
On 21 February 2017 at 16:18, Paolo Bonzini wrote: > On 21/02/2017 14:57, Peter Maydell wrote: >>> -global is a qdev thing. >> ...which reminds me to ask: is there any hope for unifying >> our properties so we don't have both "qdev properties" and >> "qom properties" or are

Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-21 Thread Paolo Bonzini
On 21/02/2017 14:57, Peter Maydell wrote: >> -global is a qdev thing. > ...which reminds me to ask: is there any hope for unifying > our properties so we don't have both "qdev properties" and > "qom properties" or are we doomed to two distinct sets of > APIs forever? We already have one set of

Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-21 Thread Markus Armbruster
Peter Maydell writes: > On 21 February 2017 at 13:56, Markus Armbruster wrote: >> -global is a qdev thing. > > ...which reminds me to ask: is there any hope for unifying > our properties so we don't have both "qdev properties" and > "qom properties"

Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-21 Thread Peter Maydell
On 21 February 2017 at 13:56, Markus Armbruster wrote: > -global is a qdev thing. ...which reminds me to ask: is there any hope for unifying our properties so we don't have both "qdev properties" and "qom properties" or are we doomed to two distinct sets of APIs forever?

Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-21 Thread Markus Armbruster
Peter Maydell writes: > On 21 February 2017 at 12:44, Igor Mammedov wrote: >> If we are to ditch legacy approach, >> It would be cleaner for SoC to have fixed/unconfigurable >> CPU type and each SoC being modeled as a separate >> QOM object/type

Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-21 Thread Igor Mammedov
On Mon, 20 Feb 2017 19:11:00 + Peter Maydell wrote: > On 20 February 2017 at 18:55, Igor Mammedov wrote: > > Peter Maydell wrote: [...] > > > its sole user netduino2 board has cpu_model hardcodded > > at board

Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-21 Thread Peter Maydell
On 21 February 2017 at 12:44, Igor Mammedov wrote: > If we are to ditch legacy approach, > It would be cleaner for SoC to have fixed/unconfigurable > CPU type and each SoC being modeled as a separate > QOM object/type that would instantiate CPU directly > with QOM style,

Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-20 Thread Peter Maydell
On 20 February 2017 at 18:55, Igor Mammedov wrote: > Peter Maydell wrote: >> This API seems a little awkward for the SoC case, where >> the board model doesn't actually know what the default >> CPU model or the valid CPU models are, because it just

Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-20 Thread Igor Mammedov
On Fri, 17 Feb 2017 19:05:20 + Peter Maydell wrote: > On 17 February 2017 at 18:56, Igor Mammedov wrote: > > Some callers call CPUClass->parse_features manually to convert > > '-cpu cpufoo,featurestr' string to cpu type and featurestr > > into

Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-17 Thread Peter Maydell
On 17 February 2017 at 18:56, Igor Mammedov wrote: > Some callers call CPUClass->parse_features manually to convert > '-cpu cpufoo,featurestr' string to cpu type and featurestr > into a set of global properties. And theni do controlled > cpu creation with setting properties

[Qemu-devel] [RFC 0/3] generalize parsing of cpu_model

2017-02-17 Thread Igor Mammedov
Some callers call CPUClass->parse_features manually to convert '-cpu cpufoo,featurestr' string to cpu type and featurestr into a set of global properties. And theni do controlled cpu creation with setting properties and completing it with realize. That's a lot of code duplication as they are