qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] [RFC 0/3] generalize parsing of cpu_model
Date: Tue, 21 Feb 2017 14:56:00 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Peter Maydell <address@hidden> writes:

> On 21 February 2017 at 12:44, Igor Mammedov <address@hidden> 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, using type name, like:
>>
>>     cpu = object_new(TYPE_FOO_CPU)
>>     set props if necessary
>>     object_property_set_bool(cpu, true, "realized", &err)
>>     object_unref(cpu)
>>
>> or similar with extra check/logic on top of plain object_new()
>>
>>     prepare cpu_opts for cpu type TYPE_FOO_CPU
>>     cpu = qdev_device_add(cpu_opts)
>>     object_unref(cpu)
>>
>> instead of using cpu_init/cpu_foo_init/cpu_generic_init()
>> with cpu_model parsing logic which is not really needed
>> there as concrete SoC model knows exact CPU type.
>
> Mmm, I think that's probably best. Would the end-user
> still be able to set CPU properties if necessary via
> a -global command line switch (since -cpu type,foo=on
> wouldn't work)?

-global is a qdev thing.  It affects only instances of TYPE_DEVICE and
its subtypes.  Since TYPE_CPU is one...

> (I just worry slightly that we might have users doing
> weird things which we'd break.)

I suspect we'd hand out a foot or two of extra rope, in addition to the
miles our users already got.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]