Hi, Am 04.09.2013 17:23, schrieb Cole Robinson: > Libvirt uses this to introspect available CPU models. > > Signed-off-by: Cole Robinson <crobi...@redhat.com> > --- > Maybe this will be centrally handled after the QOM CPU work is done?
No, this API is about a pre-QOM command line switch, whose implementation is target-specific. What got standardized for multiple targets was the CPUClass::class_by_name() hook for the opposite direction of -cpu to ObjectClass lookup (with the goal of obsoleting cpu_init()). It is not wrong to implement query-cpus for arm, but -cpu is considered deprecated. And personally especially for arm I would rather welcome someone contributing a proper, e.g., Raspberry Pi board (with clean separation of what is on the SoC and what on the board to avoid duplication among boards) than tweaking some other unrelated board with -cpu and then complaining that it doesn't work as expected. ;) For machines that use soft-core CPUs (FPGAs) or for mach-virt as non-physical machine it does make sense, but query-cpus gives us a list irrespective of whether they are compatible with the board. Same for ppc btw - plugging, e.g., a 440 CPU into pseries or mac99 won't work. Short-term my view is to use fixed CPU types, ignoring -cpu, where the CPU cannot be exchanged (e.g., DIGIC patch series) and a suitable link<> type otherwise. The long-term goal is to have machines be config files (thereby user-creatable) assembling QOM objects by specifying memory mapping and IRQ routing. The latter two parts don't work with the old qdev and SysBusDevice APIs. That said, patch itself looks correct, Reviewed-by: Andreas Färber <afaer...@suse.de> Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg