Bug 1419466
| Summary: | Hotplug memory will induce error: kvm run failed Bad address on ppc when boot up with "-mem-path /mnt/hugetlbfs" | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Min Deng <mdeng> |
| Component: | qemu-kvm-rhev | Assignee: | Thomas Huth <thuth> |
| Status: | CLOSED ERRATA | QA Contact: | Min Deng <mdeng> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.4 | CC: | dzheng, knoel, lvivier, michen, mrezanin, qzhang, virt-maint, zhengtli |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | ppc64le | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm-rhev-2.9.0-1.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-01 23:44:45 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: | |||
|
Description
Min Deng
2017-02-06 09:18:12 UTC
QE cannot reproduce it on x86 Looks very similar to:
commit 3d4f2534834cd9f9bbb3dd145fa61fd2ac0dd535
Author: Thomas Huth <thuth>
Date: Mon Jul 18 15:19:04 2016 +0200
ppc: Huge page detection mechanism fixes - Episode III
After already fixing two issues with the huge page detection mechanism
(see commit 159d2e39a860 and 86b50f2e1bef), Greg Kurz noticed another
case that caused the guest to crash where QEMU announces huge pages
though they should not be available for the guest:
qemu-system-ppc64 -enable-kvm ... -mem-path /dev/hugepages \
-m 1G,slots=4,maxmem=32G
-object memory-backend-ram,policy=default,size=1G,id=mem-mem1 \
-device pc-dimm,id=dimm-mem1,memdev=mem-mem1 -smp 2 \
-numa node,nodeid=0 -numa node,nodeid=1
That means if there is a global mem-path option, we still have
to look at the memory-backend objects that have been specified
additionally and return their minimum page size if that value
is smaller than the page size of the main memory.
But this commit is already in 2.8.0 (since 2.7.0).
Looks like kvmppc_book3s_hv_page_fault() in arch/powerpc/kvm/book3s_64_mmu_hv.c of the kernel KVM code returns -EFAULT - and this then causes the "error: kvm run failed Bad address" in QEMU... I'll try to find out why this happens... FWIW, I can also reproduce the crash with upstream QEMU, and without Numa, by simply running: qemu-system-ppc64 -enable-kvm -nographic -vga none \ -m 1G,slots=256,maxmem=32G -mem-path /mnt/hugetlbfs -hda disk.img OK, I think I've now understood what's happening here: If you add a "memory-backend-ram" object, it get's created with "normal" memory, i.e. without the hugetlbfs backup. Now, on POWER the guest can not mix normal memory regions and huge page regions (see BZ 1347498 for example), and we have to tell the guest the lowest common denominator of page sizes during boot. Since the guest has been started with huge pages only here, it thinks it can always use huge pages for all memory. So it is not possible to add memory with smaller page sizes later, and there is also no way to fix this problem on POWER, since the page sizes are communicated as CPU property during boot, i.e. it can not be communicated to the guest for memory regions that are added later. On x86, we do not have this problem since page sizes are not communicated as property of the CPU, as far as I know. So if you want to hot plug memory in this case, you have got to use a "memory-backend-file" object with "mem-path=/mnt/hugetlbfs" property instead. The only thing that we could do here is to avoid the crash by refusing to create a "memory-backend-ram" object in this case, and inform the user with an appropriate error message instead. I'll have a look at that next. (In reply to Thomas Huth from comment #6) > So if you want to hot plug memory in this case, you have got to use a > "memory-backend-file" object with "mem-path=/mnt/hugetlbfs" property > instead. The only thing that we could do here is to avoid the crash by > refusing to create a "memory-backend-ram" object in this case, and inform > the user with an appropriate error message instead. I'll have a look at that > next. I do not see any better solution either. I've now suggested a patch upstream: http://marc.info/?i=1487150504-30335-1-git-send-email-thuth@redhat.com Patch has been merged upstream: http://git.qemu-project.org/?p=qemu.git;a=commitdiff;h=df58713396f8b2deb923e39c00b10744c5c63909 We'll get it via rebase to 2.9, so setting the state to POST now. Considering comment6 and the current test results by terms of the following builds,QE verified the bug. kernel-3.10.0-655.el7.ppc64le (guest and host) qemu-kvm-rhev-2.9.0-1.el7.ppc64le SLOF-20170303-1.git66d250e.el7.noarch Steps,please refer to comment 0 Actual results,an error messages pops up comparing with its before,it is much more friendly and accurately. (qemu) object_add memory-backend-ram,id=mem1,size=1G (qemu) device_add pc-dimm,id=dimm1,memdev=mem1 Memory backend has bad page size. Use 'memory-backend-file' with correct mem-path. (qemu) Expected results, An proper error message should pop up. The issue has been fixed through providing an error message so far,it is acceptable.So QE move the bug to status verified.Thanks a lot. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2017:2392 |