On 26 January 2018 at 10:42, Eduardo Habkost <ehabk...@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
