Am 22.07.2013 13:34, schrieb Peter Maydell: > On 22 July 2013 12:17, Andreas Färber <afaer...@suse.de> wrote: >> Am 22.07.2013 12:40, schrieb Peter Maydell: >>> In any case we should be >>> consistent across target architectures about what we allow. >> >> alpha allows both [...] >> It didn't have -cpu ? before QOM, so we decided to print the type names >> there. > > Looking at all of the '-cpu help' output, alpha seems to be > the odd one out here: none of the others list valid CPUs > with "-$arch-cpu" suffixes.
Right, because all others had implemented -cpu ? before we introduced that naming scheme and I tried to keep output compatibility for them. Focus for alpha was therefore on -cpu foo compatibility only. Anthony had clearly stated on a KVM call that using full type names for future CPU hot-add was the right thing to do and possibly even composite convenience types like 4core-xeonblabla-x86_64-cpu; how that relates to -cpu and new targets was never clearly defined though. ;) For VMSD we decided to deviate for new migratable targets from legacy CPUs in favor of consistency with devices, for instance. >> Stripping -alpha-cpu off typenames would surely be possible. > > I think that that would be better in the name of consistency. > Also regarding consistency, not all targets react very well > to being asked for a nonexistent cpu via "-cpu xyzzy": > alpha and s390x just plough on without an error s390x does not have models yet. This will get fixed once we have agreed on model names and their implementation. > lm32 and unicore32 segfault > > (some of this may be default board model bugs rather than > target-* bugs). Yeah, for one sh4 board where I noticed it while refactoring I already applied an error check. I guess cpu_init() / cpu_*_init() is not NULL-checked in more machines. Not sure if trying invalid arguments would be applicable for a qtest? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
