On Fri, Jan 26, 2018 at 11:02:24AM +0000, Peter Maydell wrote:
> 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.
>
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
