[libvirt] [PATCH] Removed more AMD-specific features from cpu64-rhel* models
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(-) diff --git a/src/cpu/cpu_map.xml b/src/cpu/cpu_map.xml index 7ef230e..6a6603b 100644 --- a/src/cpu/cpu_map.xml +++ b/src/cpu/cpu_map.xml @@ -347,7 +347,6 @@ </model> <model name='cpu64-rhel6'> - <feature name='abm'/> <feature name='apic'/> <feature name='clflush'/> <feature name='cmov'/> @@ -373,7 +372,6 @@ <feature name='sse'/> <feature name='sse2'/> <feature name='pni'/> - <feature name='sse4a'/> <feature name='syscall'/> <feature name='tsc'/> </model> -- 1.7.3.4
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. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 03/08/2012 04:11 PM, 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? At any rate, ACK.
NACK, Jiri reminded me I forgot to run the tests and there is one fix missing in the xml files. The v2 is coming right up. Martin
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. Jirka
On 03/09/2012 06:44 AM, Jiri Denemark wrote:
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.
Indeed - sorting by bit value is more useful than sorting by name. But either way you look at it, the current list is not sorted :) -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (3)
-
Eric Blake -
Jiri Denemark -
Martin Kletzander