Bug 918907

Summary: provide backwards-compatible RHEL specific machine types in QEMU - CPU features
Product: Red Hat Enterprise Linux 7 Reporter: Paolo Bonzini <pbonzini>
Component: qemu-kvmAssignee: Eduardo Habkost <ehabkost>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: acathrow, ajia, areis, bdas, berrange, ehabkost, hhuang, jshortt, juzhang, kraxel, laine, michen, mrezanin, pbonzini, qzhang, scui, virt-maint
Target Milestone: rcKeywords: FutureFeature
Target Release: 7.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-1.5.3-44.el7 Doc Type: Deprecated Functionality
Doc Text:
RHEL7.0 will not provide the rhel5 machine-types. Similarly, the "cpu64-rhel5" CPU model won't be available on RHEL-7.
Story Points: ---
Clone Of: 895959
: 1011623 1011626 (view as bug list) Environment:
Last Closed: 2014-06-13 09:41:10 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 977864, 983991    
Bug Blocks: 841379, 895959, 983997, 984008, 984010, 1011623, 1011626    

Description Paolo Bonzini 2013-03-07 08:17:26 UTC
+++ This bug was initially created as a clone of Bug #895959 +++

Description of problem:
Upstream QEMU currently uses machine type names like this on x86:

$ qemu-kvm  -M ?
Supported machines are:
none                 empty machine
pc                   Standard PC (alias of pc-1.2)
pc-1.2               Standard PC (default)
pc-1.1               Standard PC
pc-1.0               Standard PC
pc-0.15              Standard PC
pc-0.14              Standard PC
pc-0.13              Standard PC
pc-0.12              Standard PC
pc-0.11              Standard PC, qemu 0.11
pc-0.10              Standard PC, qemu 0.10
isapc                ISA-only PC


This is basically a machine type prefix plus a version suffix.

With recent patch from Gerd, upstream machine type name prefixes are changing to directly reflect the hardware names:

> Starting with release 1.4 we have a fully functional q35 machine type,
> i.e. "qemu -M q35" JustWorks[tm].  Update machine type names to reflect
> that:
>
>  * pc-1.4 becomes pc-i440fx-1.4
>  * q35-next becomes pc-q35-1.4
>
> The pc-1.3 (+older) names are maintained for compatibility reasons.
> For the same reason the "pc" and "q35" aliases are kept.  pc-piix-1.4
> continues to be the default machine type, again for compatibility
> reasons.
>
> Also updated the description (shown by "qemu -M ?") with host bridge
> name, south bridge name and chipset release year.

RHEL-5/6 meanwhile have historically changed both the machine type prefix and the version string:

# qemu-system-x86_64 -M ?
Supported machines are:
pc         RHEL 6.2.0 PC (alias of rhel6.2.0)
rhel6.2.0  RHEL 6.2.0 PC (default)
rhel6.1.0  RHEL 6.1.0 PC
rhel6.0.0  RHEL 6.0.0 PC
rhel5.5.0  RHEL 5.5.0 PC
rhel5.4.4  RHEL 5.4.4 PC
rhel5.4.0  RHEL 5.4.0 PC

This was always unpleasant, but it becomes much worse when we consider the possibility of having two machine types - piix and q35.

RHEL needs to have custom versions to deal with backports, but there is no reason why it should be changing the base name prefix, nor does it need to change the descriptions.

Thus for RHEL-7 we should adjust our policy so that we only change the version suffix. So come rhel-7.3 we would have ended up with something like:

 # qemu-system-x86_64 -M ?
 Supported machines are:
 pc                   Standard PC (Q35 + ICH9, 2009) (alias of  pc-q35-rhel7.3.0)
 pc-i440fx-rhel7.0.0  Standard PC (i440FX + PIIX, 1996)
 pc-i440fx-rhel7.1.0  Standard PC (i440FX + PIIX, 1996)
 pc-i440fx-rhel7.2.0  Standard PC (i440FX + PIIX, 1996)
 pc-i440fx-rhel7.3.0  Standard PC (i440FX + PIIX, 1996)
 pc-q35-rhel7.0.0     Standard PC (Q35 + ICH9, 2009)
 pc-q35-rhel7.1.0     Standard PC (Q35 + ICH9, 2009)
 pc-q35-rhel7.2.0     Standard PC (Q35 + ICH9, 2009)
 pc-q35-rhel7.3.0     Standard PC (Q35 + ICH9, 2009) (default)

Obviously the existing machine types from RHEL-5/6 will need to keep their names for sake of backwards compatibility.

This will make it mean that RHEL machine types once again clearly show what hardware they are associated with. This is also important to libvirt since it needs to look at the name prefix to figure out the default PCI bus topology. This also reduces divergence from upstream, which is always a good thing

Version-Release number of selected component (if applicable):
1.3.0-3

--------------------------

PV CPUID features may require more work, so cloning a separate bug and assigning this to Igor.

Comment 2 Eduardo Habkost 2013-06-10 18:12:38 UTC
RHEL-6 bugs/patches to keep in mind while implementing and testing this one:

 * Bug 814426 - "rdtscp" flag defined on SandyBridge and Opteron models, but not supported by the kernel
 * Bug 874400 - "rdtscp" flag defined on Opteron_G5 model and cann't be exposed to guest

Comment 3 Eduardo Habkost 2013-08-16 03:55:00 UTC
I'm working on it using the new "qemu_cpu..full_dump" test cases on virt-test.

Comment 5 Miroslav Rezanina 2013-08-29 11:16:51 UTC
Fix included in qemu-kvm-1.5.3-2.el7

Comment 6 Eduardo Habkost 2013-09-16 20:34:22 UTC
Reopening, I have found additional compatibility issues on some CPU models (mainly AMD CPU models).

Comment 9 Miroslav Rezanina 2013-09-26 09:35:17 UTC
Fix included in qemu-kvm-1.5.3-7.el7

Comment 11 Miroslav Rezanina 2013-10-16 11:46:20 UTC
There's additional fixes for this bz - reverting to post.

Comment 12 Miroslav Rezanina 2013-10-17 10:00:44 UTC
Fix included in qemu-kvm-1.5.3-10.el7

Comment 26 Eduardo Habkost 2014-01-14 18:17:08 UTC
So, about the results:

kvm64 and cpu64-rhel6 CPU models: this is a known bug in the RHEL6 CPU models. We won't carry the bug forward when migrating, so this can be added to the config file:

diff --git a/qemu/tests/cfg/qemu_cpu.cfg b/qemu/tests/cfg/qemu_cpu.cfg
index fce9031..f2a0186 100644
--- a/qemu/tests/cfg/qemu_cpu.cfg
+++ b/qemu/tests/cfg/qemu_cpu.cfg
@@ -287,6 +287,15 @@
                             ignore_cpuid_leaves += " 0x80000001,0x0,edx,14"
                             ignore_cpuid_leaves += " 0x80000001,0x0,edx,17"
 
+                    #KNOWN BUG: RHEL-6 has broken feature aliases on
+                    # 0x80000001.EDX and they were not fixed, so ignore them:
+                    machine.rhel.rhel600, machine.rhel.rhel610, machine.rhel.rhel620, machine.rhel.rhel630, machine.rhel.rhel640:
+                        cpu.amd.athlon, cpu.amd.cpu64_rhel6, cpu.intel.kvm64:
+                            # mtrr, mca, pse36
+                            ignore_cpuid_leaves += " 0x80000001,0x0,edx,12"
+                            ignore_cpuid_leaves += " 0x80000001,0x0,edx,14"
+                            ignore_cpuid_leaves += " 0x80000001,0x0,edx,17"
+
                     # bz#819562: broken passthrough mode of CPUID leaf 7
                     machine.rhel.rhel620:
                         ignore_cpuid_leaves += " 7,0"


athlon CPU model: the bits 12, 14, 17 can be ignored like above, but there are differences in the 3dnowext and 3dnow bits. I will investigate the cause, and it will probably require a new RHEL-7 compat patch.

Comment 27 Eduardo Habkost 2014-01-14 18:31:06 UTC
About the remaining athlon CPU model differences: the RHEl-6 athlon CPU model already have 3dnow and 3dnowext, so this is likely to be a bug in the CPU model dumps instead of on RHEL-7. I need to run some tests on RHEl-6 to find it out.

Comment 28 Eduardo Habkost 2014-01-14 20:14:01 UTC
RHEL-6 has old code that (incorrectly) disables 3dnow and 3dnowext unconditionally and without any warning. So, we need to disable it on the rhel6.* machine-type compat code as well. I will submit a patch soon.

Comment 31 Miroslav Rezanina 2014-01-17 13:27:10 UTC
Fix included in qemu-kvm-1.5.3-38.el7

Comment 33 Eduardo Habkost 2014-01-22 18:16:00 UTC
You need the following update to the virt-test config:

diff --git a/qemu/tests/cfg/qemu_cpu.cfg b/qemu/tests/cfg/qemu_cpu.cfg
index 56be533..8ab9330 100644
--- a/qemu/tests/cfg/qemu_cpu.cfg
+++ b/qemu/tests/cfg/qemu_cpu.cfg
@@ -297,7 +297,7 @@
                     #KNOWN BUG: RHEL-6 has broken feature aliases on
                     # 0x80000001.EDX and they were not fixed, so ignore them:
                     machine.rhel.rhel600, machine.rhel.rhel610, machine.rhel.rhel620, machine.rhel.rhel630, machine.rhel.rhel640, machine.rhel.rhel650:
-                        cpu.amd.athlon, cpu.amd.cpu64_rhel6, cpu.intel.kvm64:
+                        cpu.amd.athlon, cpu.amd.cpu64_rhel6, cpu.intel.kvm64, cpu.amd.qemu64:
                             # vme, mtrr, mca, pse36
                             ignore_cpuid_leaves += " 0x80000001,0x0,edx,1"
                             ignore_cpuid_leaves += " 0x80000001,0x0,edx,12"

Comment 36 Eduardo Habkost 2014-01-23 17:16:20 UTC
The results look good now, but while investigating bug 1056428 I have found another issue. Patch submitted:

Subject: [RHEL7 qemu-kvm PATCH 1/2] pc: Disable RDTSCP unconditionally on rhel6.* machine-types
Date: Wed, 22 Jan 2014 23:02:20 -0200
Message-Id: <1390438941-18726-2-git-send-email-ehabkost>

Comment 37 Qunfang Zhang 2014-01-24 03:26:46 UTC
(In reply to Eduardo Habkost from comment #36)
> The results look good now, but while investigating bug 1056428 I have found
> another issue. Patch submitted:
> 
> Subject: [RHEL7 qemu-kvm PATCH 1/2] pc: Disable RDTSCP unconditionally on
> rhel6.* machine-types
> Date: Wed, 22 Jan 2014 23:02:20 -0200
> Message-Id: <1390438941-18726-2-git-send-email-ehabkost>

Hi, Eduardo

To verify this after it's included in the internal build, do we need to check the flag "rdtscp" will not be exposed to guest running on rhel7. And even with "-cpu Opteron_G5,enforce", there should no any warning?  Help fix me if it's wrong.

Thank you.
Qunfang

Comment 38 Eduardo Habkost 2014-01-24 12:06:16 UTC
(In reply to Qunfang Zhang from comment #37)
> (In reply to Eduardo Habkost from comment #36)
> > The results look good now, but while investigating bug 1056428 I have found
> > another issue. Patch submitted:
> > 
> > Subject: [RHEL7 qemu-kvm PATCH 1/2] pc: Disable RDTSCP unconditionally on
> > rhel6.* machine-types
> > Date: Wed, 22 Jan 2014 23:02:20 -0200
> > Message-Id: <1390438941-18726-2-git-send-email-ehabkost>
> 
> Hi, Eduardo
> 
> To verify this after it's included in the internal build, do we need to
> check the flag "rdtscp" will not be exposed to guest running on rhel7. And
> even with "-cpu Opteron_G5,enforce", there should no any warning?  Help fix
> me if it's wrong.

That's correct. rdtscp should be disabled on all CPU models for all rhel6.* machine-types.

On rhel7.0.0 machine-type, rdtscp should be disabled on all AMD CPU models (but it will stay enabled on SandyBridge and Haswell CPU model). (But as this bug is about rhel6 machine-types, Bug 1056428 can be used to track the rhel7.0.0 changes)

Comment 39 Qunfang Zhang 2014-01-26 02:32:22 UTC
(In reply to Eduardo Habkost from comment #38)
......
> That's correct. rdtscp should be disabled on all CPU models for all rhel6.*
> machine-types.
> 
> On rhel7.0.0 machine-type, rdtscp should be disabled on all AMD CPU models
> (but it will stay enabled on SandyBridge and Haswell CPU model). (But as
> this bug is about rhel6 machine-types, Bug 1056428 can be used to track the
> rhel7.0.0 changes)

Thanks a lot for the confirmation.

Comment 40 Miroslav Rezanina 2014-01-29 07:01:33 UTC
Fix included in qemu-kvm-1.5.3-44.el7

Comment 41 Qunfang Zhang 2014-02-07 09:53:55 UTC
Verified the scenarios Eduardo suggested in comment 38 with qemu-kvm-1.5.3-45.el7.x86_64, all the results are expected as below:

Intel Haswell host:
(1) -cpu Haswell -M pc
Guest: Has "rdtscp" flag

(2) -cpu Haswell -M rhel6.5.0
Guest: No "rdtscp" flag


Intel SandyBridge host:

(1) -cpu SandyBridge  -M pc
Guest: Has "rdtscp" flag

(2) -cpu SandyBridge  -M rhel6.5.0
Guest: No "rdtscp" flag


AMD host with "rdtscp" flag:

(1) -cpu Opteron_G5 -M pc
Guest: No "rdtscp" flag

(2) -cpu Opteron_G5 -M rhel6.5.0
Guest: No "rdtscp" flag

(3) -cpu Opteron_G4 -M pc
Guest: No "rdtscp" flag

(4) -cpu Opteron_G4 -M rhel6.5.0
Guest: No "rdtscp" flag

(5) -cpu Opteron_G3 -M rhel6.5.0
Guest: No "rdtscp" flag

(6) -cpu Opteron_G2 -M rhel6.5.0
Guest: No "rdtscp" flag

Comment 42 Qunfang Zhang 2014-02-07 09:55:31 UTC
Based on comment 15, comment 34, comment 41, this bug is fixed.

Comment 45 Ludek Smid 2014-06-13 09:41:10 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.