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 1619166 - Guest kernel panic when it's started with topoext flag
Summary: Guest kernel panic when it's started with topoext flag
Keywords:
Status: CLOSED DUPLICATE of bug 1615682
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Eduardo Habkost
QA Contact: Guo, Zhiyi
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-20 08:48 UTC by Jing Qi
Modified: 2019-06-24 17:20 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-24 17:20:47 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Jing Qi 2018-08-20 08:48:04 UTC 
Description of problem:
Guest kernel panic when it's started with topoext flag

Version-Release number of selected component (if applicable):
Host kernel version:
[root@hp-dl385g7-xx~]# uname -a
Linux hp-dl385g7-xx.lab.eng.pek2.redhat.com 3.10.0-931.el7.x86_64 #1 SMP Tue Jul 31 17:55:24 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux

And Guest kernel version:
Linux localhost.localdomain 3.10.0-933.el7.x86_64 #1 SMP Sat Aug 11 11:32:57 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux

How reproducible:
Always


Steps to Reproduce:
1. Define a guest vm with topoext enable:
<cpu mode='custom' match='exact' check='full'>
    <model fallback='allow'>Opteron_G3</model>
    <vendor>AMD</vendor>
    <feature policy='require' name='topoext'/>
...
</cpu>

2.Tried to start the vm and kernel panic

  [  110.721000] Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014
[  110.721000] task: ffffffffbd818480 ti: ffffffffbd800000 task.ti: ffffffffbd800000
[  110.721000] RIP: 0010:[<ffffffffbccb7472>]  [<ffffffffbccb7472>] __queue_work+0x32/0x3e0
[  110.721000] RSP: 0000:ffff94a1fec03e20  EFLAGS: 00010046
[  110.721000] RAX: 0000000000000082 RBX: 0000000000000087 RCX: 0000000000000000
[  110.721000] RDX: ffffffffbd8eea20 RSI: 0000000000000000 RDI: 0000000000001400
[  110.721000] RBP: ffff94a1fec03e58 R08: 0000000000000000 R09: 0000000000004000
[  110.721000] R10: ffffffffbde36cb4 R11: 0000000000007ffe R12: ffffffffbd8eea20
[  110.721000] R13: 0000000000001400 R14: 0000000000000000 R15: ffffffffbd6c1ac6
[  110.721000] FS:  0000000000000000(0000) GS:ffff94a1fec00000(0000) knlGS:0000000000000000
[  110.721000] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  110.721000] CR2: 0000000000000102 CR3: 0000000040c10000 CR4: 00000000000006b0
[  110.721000] Call Trace:
[  110.721000]  <IRQ>
[  110.721000]  [<ffffffffbccb7a75>] queue_work_on+0x45/0x50
[  110.721000]  [<ffffffffbd083a16>] credit_entropy_bits+0x1c6/0x290
[  110.721000]  [<ffffffffbd084724>] ? add_interrupt_randomness+0x1c4/0x230
[  110.721000]  [<ffffffffbd084724>] add_interrupt_randomness+0x1c4/0x230
[  110.721000]  [<ffffffffbcd49d2f>] handle_irq_event_percpu+0x3f/0x80
[  110.721000]  [<ffffffffbcd49dac>] handle_irq_event+0x3c/0x60
[  110.721000]  [<ffffffffbcd4ceb3>] handle_level_irq+0x73/0xd0
[  110.721000]  [<ffffffffbcc2e564>] handle_irq+0xe4/0x1a0
[  110.721000]  [<ffffffffbcc9fac8>] ? __local_bh_enable+0x28/0x90
[  110.721000]  [<ffffffffbd37755d>] do_IRQ+0x4d/0xf0
[  110.721000]  [<ffffffffbd369362>] common_interrupt+0x162/0x162
[  110.721000]  <EOI>
[  110.721000]  [<ffffffffbd3694a6>] ? retint_restore_args+0x6/0x36
[  110.721000]  [<ffffffffbcc6a511>] ? native_cpuid+0x11/0x20
[  110.721000]  [<ffffffffbcc3c61e>] find_num_cache_leaves.isra.0+0x6e/0xa0
[  110.721000]  [<ffffffffbcc3dc59>] init_amd_cacheinfo+0x99/0xb0
[  110.721000]  [<ffffffffbcc4230e>] init_amd+0x23e/0x7d0
[  110.721000]  [<ffffffffbcc3f772>] identify_cpu+0x1c2/0x4d0
[  110.721000]  [<ffffffffbd994f49>] identify_boot_cpu+0x10/0xa9
[  110.721000]  [<ffffffffbd995107>] check_bugs+0x21/0x2b6
[  110.721000]  [<ffffffffbd98619d>] start_kernel+0x422/0x46c
[  110.721000]  [<ffffffffbd985b7b>] ? repair_env_string+0x5c/0x5c
[  110.721000]  [<ffffffffbd985120>] ? early_idt_handler_array+0x120/0x120
[  110.721000]  [<ffffffffbd98572f>] x86_64_start_reservations+0x24/0x26
[  110.721000]  [<ffffffffbd985885>] x86_64_start_kernel+0x154/0x177
[  110.721000]  [<ffffffffbcc000d5>] start_cpu+0x5/0x14
[  110.721000] Code: 89 e5 41 57 41 56 49 89 f6 41 55 41 89 fd 41 54 49 89 d4 53 48 83 ec 10 89 7d d4 ff 14 25 80 40 83 bd f6 c4 02 0f 85 de 02 00 00 <41> f6 86 02 01 00 00 01 0f 85 78 02 00 00 49 c7 c7 48 7b 01 00
[  110.721000] RIP  [<ffffffffbccb7472>] __queue_work+0x32/0x3e0
[  110.721000]  RSP <ffff94a1fec03e20>
[  110.721000] CR2: 0000000000000102
[  110.721000] ---[ end trace 6b1656b8c12001c3 ]---
[  110.721000] Kernel panic - not syncing: Fatal exception in interrupt

3. Edit the vm xml to -
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='allow'>Opteron_G3</model>
    <vendor>AMD</vendor>
    <feature policy='disable' name='topoext'/>
....
4. VM can be started successfully.

Actual results:

Kernel panic with topoext flag.

Expected results:

No kernel panic with topoext flag.

Additional info:
Comment 4 Eduardo Habkost 2019-06-24 17:20:47 UTC 
This has the same cause of bug 1615682.  It is a known limitation of the TOPOEXT implementation in QEMU (which works only with the EPYC CPU model), and will probably be fixed only in QEMU 4.2.

*** This bug has been marked as a duplicate of bug 1615682 ***
Note You need to log in before you can comment on or make changes to this bug.