This patchset adds support for '-cpu max' to Arm, along the lines
of the existing support we have for x86 targets:

 * under KVM, -cpu max is the same as -cpu host
 * under TCG, -cpu max means "emulate with as many features as
   possible"

-cpu max is supported for both usermode and system emulation,
again following the x86 line.

NB that cross-QEMU-version migration is not supported for -cpu max:
in future the definition of "maximum set of features" will change
as we add more emulation features.

The patchset also adds support to the virt board for the "max"
option to -machine gic-version, requesting "best available
interrupt controller", with the same semantics as -cpu max.

Together these should assist users like libguestfs that just want
to be able to run code without having to figure out what the
right command line arguments for this particular host system are.


Patch 1 is a bugfix, needed because now "-cpu host" without
-enable-kvm will only be detected when the CPU object fails
realize, rather than because we don't register the 'host'
CPU type at all.

(This is something that I meant to do much earlier: see
https://lists.gnu.org/archive/html/qemu-devel/2017-02/msg06183.html
but at the time we were about to freeze for 2.9, so it fell
off my immediate todo list and then I never got back to it...)

thanks
-- PMM

Peter Maydell (6):
  hw/arm/virt: Check that the CPU realize method succeeded
  target/arm: Query host CPU features on-demand at instance init
  target/arm: Move definition of 'host' cpu type into cpu.c
  target/arm: Add "-cpu max" support
  hw/arm/virt: Add "max" to the list of CPU types "virt" supports
  hw/arm/virt: Support -machine gic-version=max

 target/arm/cpu-qom.h |  2 ++
 target/arm/cpu.h     |  5 +++++
 target/arm/kvm_arm.h | 35 ++++++++++++++++++++----------
 hw/arm/virt.c        | 32 +++++++++++++++++----------
 target/arm/cpu.c     | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 target/arm/cpu64.c   | 21 ++++++++++++++++++
 target/arm/kvm.c     | 51 +++++++++++++++----------------------------
 target/arm/kvm32.c   |  8 +++----
 target/arm/kvm64.c   |  8 +++----
 9 files changed, 159 insertions(+), 64 deletions(-)

-- 
2.7.4

On 7 December 2017 at 18:14, Peter Maydell <peter.maydell@linaro.org> wrote:
> This patchset adds support for '-cpu max' to Arm, along the lines
> of the existing support we have for x86 targets:
>
>  * under KVM, -cpu max is the same as -cpu host
>  * under TCG, -cpu max means "emulate with as many features as
>    possible"

Forgot to mention: -cpu max for qemu-system-aarch64 will
be a 64-bit cpu, and for qemu-system-arm it will be a 32-bit
cpu. (This differs from all the other TCG CPU types, which
behave the same for the 32-bit and 64-bit binaries. I think
it is the same way that x86 -cpu max works, though.)

thanks
-- PMM

On Thu, Dec 07, 2017 at 07:37:31PM +0000, Peter Maydell wrote:
> On 7 December 2017 at 18:14, Peter Maydell <peter.maydell@linaro.org> wrote:
> > This patchset adds support for '-cpu max' to Arm, along the lines
> > of the existing support we have for x86 targets:
> >
> >  * under KVM, -cpu max is the same as -cpu host
> >  * under TCG, -cpu max means "emulate with as many features as
> >    possible"
> 
> Forgot to mention: -cpu max for qemu-system-aarch64 will
> be a 64-bit cpu, and for qemu-system-arm it will be a 32-bit
> cpu. (This differs from all the other TCG CPU types, which
> behave the same for the 32-bit and 64-bit binaries. I think
> it is the same way that x86 -cpu max works, though.)

Are they going to be represented by two different QOM type names?

(In the case of x86, all the CPU classes have different names on
qemu-system-x86_64 and qemu-system-i386).

-- 
Eduardo

On 9 December 2017 at 01:08, Eduardo Habkost <ehabkost@redhat.com> wrote:
> On Thu, Dec 07, 2017 at 07:37:31PM +0000, Peter Maydell wrote:
>> On 7 December 2017 at 18:14, Peter Maydell <peter.maydell@linaro.org> wrote:
>> > This patchset adds support for '-cpu max' to Arm, along the lines
>> > of the existing support we have for x86 targets:
>> >
>> >  * under KVM, -cpu max is the same as -cpu host
>> >  * under TCG, -cpu max means "emulate with as many features as
>> >    possible"
>>
>> Forgot to mention: -cpu max for qemu-system-aarch64 will
>> be a 64-bit cpu, and for qemu-system-arm it will be a 32-bit
>> cpu. (This differs from all the other TCG CPU types, which
>> behave the same for the 32-bit and 64-bit binaries. I think
>> it is the same way that x86 -cpu max works, though.)
>
> Are they going to be represented by two different QOM type names?
>
> (In the case of x86, all the CPU classes have different names on
> qemu-system-x86_64 and qemu-system-i386).

(Just pulling this thread up from before Christmas...)

I guess a better way to approach this would be to ask: how is
x86 implementing -cpu max, ie what is the required view of things
that I need to provide for target/arm in order to have QEMU
behave the same way x86 does? Did we write any user-facing
documentation for this feature?

(The code in this patchset makes '-cpu max' give the same
QOM type name for both qemu-system-arm and qemu-system-aarch64,
with different behaviour depending on the binary. If that means
we don't provide the same behaviour as x86 then I can change that,
but I'm not sure where the difference is exposed to the user?)

thanks
-- PMM

On Mon, Jan 22, 2018 at 06:06:26PM +0000, Peter Maydell wrote:
> On 9 December 2017 at 01:08, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > On Thu, Dec 07, 2017 at 07:37:31PM +0000, Peter Maydell wrote:
> >> On 7 December 2017 at 18:14, Peter Maydell <peter.maydell@linaro.org> wrote:
> >> > This patchset adds support for '-cpu max' to Arm, along the lines
> >> > of the existing support we have for x86 targets:
> >> >
> >> >  * under KVM, -cpu max is the same as -cpu host
> >> >  * under TCG, -cpu max means "emulate with as many features as
> >> >    possible"
> >>
> >> Forgot to mention: -cpu max for qemu-system-aarch64 will
> >> be a 64-bit cpu, and for qemu-system-arm it will be a 32-bit
> >> cpu. (This differs from all the other TCG CPU types, which
> >> behave the same for the 32-bit and 64-bit binaries. I think
> >> it is the same way that x86 -cpu max works, though.)
> >
> > Are they going to be represented by two different QOM type names?
> >
> > (In the case of x86, all the CPU classes have different names on
> > qemu-system-x86_64 and qemu-system-i386).
> 
> (Just pulling this thread up from before Christmas...)
> 
> I guess a better way to approach this would be to ask: how is
> x86 implementing -cpu max, ie what is the required view of things
> that I need to provide for target/arm in order to have QEMU
> behave the same way x86 does? Did we write any user-facing
> documentation for this feature?

About QOM type names:

On x86, all CPU models are resolved to "<model>-<suffix>", and
i386 and x86_64 have different suffixes.  So the QOM type name is
"max-x86_64-cpu" on qemu-system-x86_64, and "max-i386-cpu" on
qemu-system-i386.

About the implementation:

On x86, the most important differences between CPU models are on
(boolean) CPUID feature flags.  "max" just set all feature flags
to *get_supported_cpuid(...), meaning all features supported by
the host will be enabled.  The other fields (e.g. CPU
vendor/family/model IDs) depend on the accelerator: on TCG we use
constant values, on KVM we use the host CPU values).

About how it should behave:

An important expectation about "max" is about the
query-cpu-model-expansion return value.  Having a property set to
true on the return value of "query-cpu-model-expansion model=max"
means the corresponding feature is supported on the current host
and can be enabled on the command-line.

The most important user-facing documentation related to "max" is
the query-cpu-model-* QMP docs.  It probably needs to be updated
to contain more specific details about how "max" behaves.
Probably we could have automated tests to confirm if some
expectations are really fulfilled.


> 
> (The code in this patchset makes '-cpu max' give the same
> QOM type name for both qemu-system-arm and qemu-system-aarch64,
> with different behaviour depending on the binary. If that means
> we don't provide the same behaviour as x86 then I can change that,
> but I'm not sure where the difference is exposed to the user?)

This is not how the QOM names work on x86, but I don't think QOM
type names choices have important user-visible side-effects
today.  Choosing unique QOM type names is more important to make
the code future-proof for when we merge QEMU binaries, than to
make user-visible behavior consistent.

-- 
Eduardo

On 22 January 2018 at 18:33, Eduardo Habkost <ehabkost@redhat.com> wrote:
> About QOM type names:
>
> On x86, all CPU models are resolved to "<model>-<suffix>", and
> i386 and x86_64 have different suffixes.  So the QOM type name is
> "max-x86_64-cpu" on qemu-system-x86_64, and "max-i386-cpu" on
> qemu-system-i386.

OK. Looking at the target/arm code we do a similar suffix
trick, but we seem to have cut-n-pasted the handling in
aarch64_cpu_register(), so it uses the TYPE_ARM_CPU as the
suffix, rather the TYPE_AARCH64_CPU.

Am I right in thinking that we can fix this (changing the
QOM type names for all the aarch64 CPUs) without breaking
migration? (I guess I can just test this easily enough.)

If we did that then we'd have, like x86, "max-arm-cpu" in
the qemu-system-arm binary, and "max-aarch64-cpu" in
the qemu-system-aarch64 binary.

Does x86 provide a way to say "give me the max-i386-cpu"
in the qemu-system-x86_64 binary ?

> About how it should behave:
>
> An important expectation about "max" is about the
> query-cpu-model-expansion return value.  Having a property set to
> true on the return value of "query-cpu-model-expansion model=max"
> means the corresponding feature is supported on the current host
> and can be enabled on the command-line.

On Arm when I try to use this I get:
{ "execute": "query-cpu-model-expansion", "arguments": { "type":
"static", "model": { "model": { "name": "max" } } } }
{
    "error": {
        "class": "CommandNotFound",
        "desc": "The command query-cpu-model-expansion has not been found"
    }
}

It looks like we only implement this QMP API for x86 and S390
(via #ifdeffery in monitor.c).

I'm not sure if we actually support command line setting/unsetting
of features for Arm CPUs -- is there a command line option to
get QEMU to print the features it thinks can be set this way?

>> (The code in this patchset makes '-cpu max' give the same
>> QOM type name for both qemu-system-arm and qemu-system-aarch64,
>> with different behaviour depending on the binary. If that means
>> we don't provide the same behaviour as x86 then I can change that,
>> but I'm not sure where the difference is exposed to the user?)
>
> This is not how the QOM names work on x86, but I don't think QOM
> type names choices have important user-visible side-effects
> today.  Choosing unique QOM type names is more important to make
> the code future-proof for when we merge QEMU binaries, than to
> make user-visible behavior consistent.

Good point -- assuming it doesn't break migration I can fix
the aarch64 types to use the right suffix string and then they'll
have different QOM type names.

thanks
-- PMM

On 25 January 2018 at 14:41, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 22 January 2018 at 18:33, Eduardo Habkost <ehabkost@redhat.com> wrote:
>> About QOM type names:
>>
>> On x86, all CPU models are resolved to "<model>-<suffix>", and
>> i386 and x86_64 have different suffixes.  So the QOM type name is
>> "max-x86_64-cpu" on qemu-system-x86_64, and "max-i386-cpu" on
>> qemu-system-i386.
>
> OK. Looking at the target/arm code we do a similar suffix
> trick, but we seem to have cut-n-pasted the handling in
> aarch64_cpu_register(), so it uses the TYPE_ARM_CPU as the
> suffix, rather the TYPE_AARCH64_CPU.

...and that's not as simple a fix as I thought, because the
code in helper.c for implementing arch_query_cpu_definitions() and
arm_cpu_list() assumes it can create the QOM type name by appending
TYPE_ARM_CPU. The ARM_CPU_TYPE_NAME() macro which we use pretty
extensively also assumes the suffix is the same regardless of
what CPU type it's being applied to.

Looking at x86 it seems that TYPE_X86_CPU expands to a different
string for qemu-system-x86_64 and qemu-system-i386. I could do
that, but it seems very confusing: I would expect a QOM type
name like TYPE_FOO to always mean the same QOM type.

Given that the type names don't appear to the user, I think
we can go ahead with implementing "-cpu max" for Arm without
having to first disentangle this? "max" isn't in any worse
a position than the existing "host" and "any" types.

thanks
-- PMM

On Thu, Jan 25, 2018 at 03:10:31PM +0000, Peter Maydell wrote:
> On 25 January 2018 at 14:41, Peter Maydell <peter.maydell@linaro.org> wrote:
> > On 22 January 2018 at 18:33, Eduardo Habkost <ehabkost@redhat.com> wrote:
> >> About QOM type names:
> >>
> >> On x86, all CPU models are resolved to "<model>-<suffix>", and
> >> i386 and x86_64 have different suffixes.  So the QOM type name is
> >> "max-x86_64-cpu" on qemu-system-x86_64, and "max-i386-cpu" on
> >> qemu-system-i386.
> >
> > OK. Looking at the target/arm code we do a similar suffix
> > trick, but we seem to have cut-n-pasted the handling in
> > aarch64_cpu_register(), so it uses the TYPE_ARM_CPU as the
> > suffix, rather the TYPE_AARCH64_CPU.
> 
> ...and that's not as simple a fix as I thought, because the
> code in helper.c for implementing arch_query_cpu_definitions() and
> arm_cpu_list() assumes it can create the QOM type name by appending
> TYPE_ARM_CPU. The ARM_CPU_TYPE_NAME() macro which we use pretty
> extensively also assumes the suffix is the same regardless of
> what CPU type it's being applied to.
> 
> Looking at x86 it seems that TYPE_X86_CPU expands to a different
> string for qemu-system-x86_64 and qemu-system-i386. I could do
> that, but it seems very confusing: I would expect a QOM type
> name like TYPE_FOO to always mean the same QOM type.

Yeah, I don't like the way TYPE_x86_CPU works, and I don't
recommend doing the same elsewhere.

> 
> Given that the type names don't appear to the user, I think
> we can go ahead with implementing "-cpu max" for Arm without
> having to first disentangle this? "max" isn't in any worse
> a position than the existing "host" and "any" types.

Sounds reasonable to me.

-- 
Eduardo

On Thu, Jan 25, 2018 at 02:41:50PM +0000, Peter Maydell wrote:
> On 22 January 2018 at 18:33, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > About QOM type names:
> >
> > On x86, all CPU models are resolved to "<model>-<suffix>", and
> > i386 and x86_64 have different suffixes.  So the QOM type name is
> > "max-x86_64-cpu" on qemu-system-x86_64, and "max-i386-cpu" on
> > qemu-system-i386.
> 
> OK. Looking at the target/arm code we do a similar suffix
> trick, but we seem to have cut-n-pasted the handling in
> aarch64_cpu_register(), so it uses the TYPE_ARM_CPU as the
> suffix, rather the TYPE_AARCH64_CPU.
> 
> Am I right in thinking that we can fix this (changing the
> QOM type names for all the aarch64 CPUs) without breaking
> migration? (I guess I can just test this easily enough.)

This is not supposed to affect migration (at least it didn't when
we introduced per-cpu-model subclasses), but it's a good idea to
test it anyway.  It might break other code that tries to extract
info from the class names.


> 
> If we did that then we'd have, like x86, "max-arm-cpu" in
> the qemu-system-arm binary, and "max-aarch64-cpu" in
> the qemu-system-aarch64 binary.
> 
> Does x86 provide a way to say "give me the max-i386-cpu"
> in the qemu-system-x86_64 binary ?

No, the *-i386-cpu classes aren't even compiled in on
qemu-system-x86_64.

> 
> > About how it should behave:
> >
> > An important expectation about "max" is about the
> > query-cpu-model-expansion return value.  Having a property set to
> > true on the return value of "query-cpu-model-expansion model=max"
> > means the corresponding feature is supported on the current host
> > and can be enabled on the command-line.
> 
> On Arm when I try to use this I get:
> { "execute": "query-cpu-model-expansion", "arguments": { "type":
> "static", "model": { "model": { "name": "max" } } } }
> {
>     "error": {
>         "class": "CommandNotFound",
>         "desc": "The command query-cpu-model-expansion has not been found"
>     }
> }
> 
> It looks like we only implement this QMP API for x86 and S390
> (via #ifdeffery in monitor.c).
> 
> I'm not sure if we actually support command line setting/unsetting
> of features for Arm CPUs -- is there a command line option to
> get QEMU to print the features it thinks can be set this way?

Unfortunately -cpu command-line parsing is still a mess (we
currently have lots of arch-specific parsing hooks).  Once we
make this uniform across targets, we could make "-cpu ?" print
all known properties.

But you can look at the list of QOM properties for your CPU
classes (-cpu options are simply translated to QOM properties).
e.g.:

  (QEMU) device-list-properties typename=pxa270-a0-arm-cpu
  {"return": [{"type": "uint32", "name": "midr"}, {"type": "uint64", "name": "mp-affinity"}, {"type": "child<irq>", "name": "unnamed-gpio-in[0]"}, {"type": "uint32", "name": "psci-conduit"}, {"type": "bool", "name": "reset-hivecs"}, {"type": "link<qemu:memory-region>", "name": "memory"}, {"type": "link<irq>", "name": "unnamed-gpio-out[2]"}, {"type": "link<irq>", "name": "unnamed-gpio-out[3]"}, {"type": "int32", "name": "node-id"}, {"type": "bool", "name": "start-powered-off"}, {"type": "link<irq>", "name": "unnamed-gpio-out[1]"}, {"type": "link<irq>", "name": "unnamed-gpio-out[0]"}, {"type": "link<irq>", "name": "gicv3-maintenance-interrupt[0]"}, {"type": "bool", "name": "cfgend"}, {"type": "child<irq>", "name": "unnamed-gpio-in[2]"}, {"type": "child<irq>", "name": "unnamed-gpio-in[3]"}, {"type": "child<irq>", "name": "unnamed-gpio-in[1]"}]}



> 
> >> (The code in this patchset makes '-cpu max' give the same
> >> QOM type name for both qemu-system-arm and qemu-system-aarch64,
> >> with different behaviour depending on the binary. If that means
> >> we don't provide the same behaviour as x86 then I can change that,
> >> but I'm not sure where the difference is exposed to the user?)
> >
> > This is not how the QOM names work on x86, but I don't think QOM
> > type names choices have important user-visible side-effects
> > today.  Choosing unique QOM type names is more important to make
> > the code future-proof for when we merge QEMU binaries, than to
> > make user-visible behavior consistent.
> 
> Good point -- assuming it doesn't break migration I can fix
> the aarch64 types to use the right suffix string and then they'll
> have different QOM type names.
> 
> thanks
> -- PMM

-- 
Eduardo

On 26 January 2018 at 10:42, Eduardo Habkost <ehabkost@redhat.com> wrote:
> On Thu, Jan 25, 2018 at 02:41:50PM +0000, Peter Maydell wrote:
>> I'm not sure if we actually support command line setting/unsetting
>> of features for Arm CPUs -- is there a command line option to
>> get QEMU to print the features it thinks can be set this way?
>
> Unfortunately -cpu command-line parsing is still a mess (we
> currently have lots of arch-specific parsing hooks).  Once we
> make this uniform across targets, we could make "-cpu ?" print
> all known properties.
>
> But you can look at the list of QOM properties for your CPU
> classes (-cpu options are simply translated to QOM properties).
> e.g.:
>
>   (QEMU) device-list-properties typename=pxa270-a0-arm-cpu
>   {"return": [{"type": "uint32", "name": "midr"}, {"type": "uint64", "name": "mp-affinity"}, {"type": "child<irq>", "name": "unnamed-gpio-in[0]"}, {"type": "uint32", "name": "psci-conduit"}, {"type": "bool", "name": "reset-hivecs"}, {"type": "link<qemu:memory-region>", "name": "memory"}, {"type": "link<irq>", "name": "unnamed-gpio-out[2]"}, {"type": "link<irq>", "name": "unnamed-gpio-out[3]"}, {"type": "int32", "name": "node-id"}, {"type": "bool", "name": "start-powered-off"}, {"type": "link<irq>", "name": "unnamed-gpio-out[1]"}, {"type": "link<irq>", "name": "unnamed-gpio-out[0]"}, {"type": "link<irq>", "name": "gicv3-maintenance-interrupt[0]"}, {"type": "bool", "name": "cfgend"}, {"type": "child<irq>", "name": "unnamed-gpio-in[2]"}, {"type": "child<irq>", "name": "unnamed-gpio-in[3]"}, {"type": "child<irq>", "name": "unnamed-gpio-in[1]"}]}

None of those are things we'd want to expose to the user, really
(except maybe 'cfgend'): they're all intended for the QEMU board
or SoC code that needs to configure and wire the CPU up. Ideally
there'd be a mechanism for screening them out of the -cpu option
list.

There are some things that we could in theory have as user
settable properties (like "does this CPU have an FPU"), but
we don't currently have QOM properties for them (each CPU
just hardcodes which ARM_FEATURE_* flags it has).

In your other email you write:
> I wrote:
>> Given that the type names don't appear to the user, I think
>> we can go ahead with implementing "-cpu max" for Arm without
>> having to first disentangle this? "max" isn't in any worse
>> a position than the existing "host" and "any" types.
>
>Sounds reasonable to me.

Cool. I think that means that patches 2-6 here don't need
any changes, but I'll rebase, retest and resend just to
avoid confusion.

thanks
-- PMM

On Fri, Jan 26, 2018 at 11:02:24AM +0000, Peter Maydell wrote:
> On 26 January 2018 at 10:42, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > On Thu, Jan 25, 2018 at 02:41:50PM +0000, Peter Maydell wrote:
> >> I'm not sure if we actually support command line setting/unsetting
> >> of features for Arm CPUs -- is there a command line option to
> >> get QEMU to print the features it thinks can be set this way?
> >
> > Unfortunately -cpu command-line parsing is still a mess (we
> > currently have lots of arch-specific parsing hooks).  Once we
> > make this uniform across targets, we could make "-cpu ?" print
> > all known properties.
> >
> > But you can look at the list of QOM properties for your CPU
> > classes (-cpu options are simply translated to QOM properties).
> > e.g.:
> >
> >   (QEMU) device-list-properties typename=pxa270-a0-arm-cpu
> >   {"return": [{"type": "uint32", "name": "midr"}, {"type": "uint64", "name": "mp-affinity"}, {"type": "child<irq>", "name": "unnamed-gpio-in[0]"}, {"type": "uint32", "name": "psci-conduit"}, {"type": "bool", "name": "reset-hivecs"}, {"type": "link<qemu:memory-region>", "name": "memory"}, {"type": "link<irq>", "name": "unnamed-gpio-out[2]"}, {"type": "link<irq>", "name": "unnamed-gpio-out[3]"}, {"type": "int32", "name": "node-id"}, {"type": "bool", "name": "start-powered-off"}, {"type": "link<irq>", "name": "unnamed-gpio-out[1]"}, {"type": "link<irq>", "name": "unnamed-gpio-out[0]"}, {"type": "link<irq>", "name": "gicv3-maintenance-interrupt[0]"}, {"type": "bool", "name": "cfgend"}, {"type": "child<irq>", "name": "unnamed-gpio-in[2]"}, {"type": "child<irq>", "name": "unnamed-gpio-in[3]"}, {"type": "child<irq>", "name": "unnamed-gpio-in[1]"}]}
> 
> None of those are things we'd want to expose to the user, really
> (except maybe 'cfgend'): they're all intended for the QEMU board
> or SoC code that needs to configure and wire the CPU up. Ideally
> there'd be a mechanism for screening them out of the -cpu option
> list.
> 

Yeah, it's becoming clearer to me that we need to address this
better than with a simple "x-" prefix convention.

If we remove the link and child properties, we have:

midr (uint32)
mp-affinity (uint64)
psci-conduit (uint32)
reset-hivecs (bool)
node-id (int32)
start-powered-off (bool)
cfgend (bool)

I wonder how many of them aren't useful with -cpu but might be
useful with -device in the future.


> There are some things that we could in theory have as user
> settable properties (like "does this CPU have an FPU"), but
> we don't currently have QOM properties for them (each CPU
> just hardcodes which ARM_FEATURE_* flags it has).
> 
> In your other email you write:
> > I wrote:
> >> Given that the type names don't appear to the user, I think
> >> we can go ahead with implementing "-cpu max" for Arm without
> >> having to first disentangle this? "max" isn't in any worse
> >> a position than the existing "host" and "any" types.
> >
> >Sounds reasonable to me.
> 
> Cool. I think that means that patches 2-6 here don't need
> any changes, but I'll rebase, retest and resend just to
> avoid confusion.
> 
> thanks
> -- PMM

-- 
Eduardo

On 26 January 2018 at 17:54, Eduardo Habkost <ehabkost@redhat.com> wrote:
> On Fri, Jan 26, 2018 at 11:02:24AM +0000, Peter Maydell wrote:
>> None of those are things we'd want to expose to the user, really
>> (except maybe 'cfgend'): they're all intended for the QEMU board
>> or SoC code that needs to configure and wire the CPU up. Ideally
>> there'd be a mechanism for screening them out of the -cpu option
>> list.
>>
>
> Yeah, it's becoming clearer to me that we need to address this
> better than with a simple "x-" prefix convention.
>
> If we remove the link and child properties, we have:
>
> midr (uint32)
> mp-affinity (uint64)
> psci-conduit (uint32)
> reset-hivecs (bool)
> node-id (int32)
> start-powered-off (bool)
> cfgend (bool)
>
> I wonder how many of them aren't useful with -cpu but might be
> useful with -device in the future.

It would require a lot of work to be able to create an Arm CPU
with -device -- there's no way at the moment to wire it up
to the interrupt controller...

thanks
-- PMM