On 03/08/2012 08:02 AM, Martin Kletzander wrote: > We found few more AMD-specific features in cpu64-rhel* models that > made it impossible to start qemu guest on Intel host (with this > setting) even though qemu itself starts correctly with them. > --- > src/cpu/cpu_map.xml | 2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > @@ -373,7 +372,6 @@ > <feature name='sse'/> > <feature name='sse2'/> > <feature name='pni'/> > - <feature name='sse4a'/> Should we use this opportunity to sort the remaining feature names? At any rate, ACK.

On Thu, Mar 08, 2012 at 08:11:24 -0700, Eric Blake wrote: > On 03/08/2012 08:02 AM, Martin Kletzander wrote: >> We found few more AMD-specific features in cpu64-rhel* models that >> made it impossible to start qemu guest on Intel host (with this >> setting) even though qemu itself starts correctly with them. >> --- >> src/cpu/cpu_map.xml | 2 -- >> 1 files changed, 0 insertions(+), 2 deletions(-) >> > >> @@ -373,7 +372,6 @@ >> <feature name='sse'/> >> <feature name='sse2'/> >> <feature name='pni'/> >> - <feature name='sse4a'/> > > Should we use this opportunity to sort the remaining feature names? I haven't checked the ordering of features in these two models but all other models should have features sorted according to their bit values and I think that's what we should stick with. It's easier to visually compare such models with /proc/cpuinfo or qemu model definitions where features are also sorted that way. Sorting them alphabetically doesn't make much sense.