RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 918907 - provide backwards-compatible RHEL specific machine types in QEMU - CPU features
Summary: provide backwards-compatible RHEL specific machine types in QEMU - CPU features
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 7.0
Assignee: Eduardo Habkost
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 977864 983991
Blocks: 841379 895959 983997 984008 984010 1011623 1011626
TreeView+ depends on / blocked
 
Reported: 2013-03-07 08:17 UTC by Paolo Bonzini
Modified: 2014-06-18 12:24 UTC (History)
17 users (show)

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.
Clone Of: 895959
: 1011623 1011626 (view as bug list)
Environment:
Last Closed: 2014-06-13 09:41:10 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.