Bug 638468
Summary: | [qemu-kvm] bochs vga lfb @ 0xe0000000 causes trouble for hot-plug | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Joy Pu <ypu> | |
Component: | qemu-kvm | Assignee: | Gerd Hoffmann <kraxel> | |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | |
Severity: | medium | Docs Contact: | ||
Priority: | medium | |||
Version: | 6.0 | CC: | alex.williamson, amit.shah, chayang, Jes.Sorensen, kcao, kraxel, lihuang, mhusnain, mkenneth, tburke, virt-maint | |
Target Milestone: | beta | |||
Target Release: | 6.1 | |||
Hardware: | All | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | qemu-kvm-0.12.1.2-2.134.el6 | Doc Type: | Bug Fix | |
Doc Text: |
Previously, when a pass-through device was plugged into an operational guest on qemu-kvn, the process failed with "create_userspace_phys_mem: File exists. assigned_dev_iomem_map: Error: create new mapping failed" error. This error occurred because qemu-kvn attempted to use the memory address 0xe0000000, which was reserved for another process. This is now fixed and qemu-kvn no longer attempts to use the reserved memory at the location 0xe0000000.
|
Story Points: | --- | |
Clone Of: | ||||
: | 654639 (view as bug list) | Environment: | ||
Last Closed: | 2011-05-19 11:29:25 UTC | Type: | --- | |
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: | ||||
Bug Blocks: | 580954, 654639 |
Description
Joy Pu
2010-09-29 04:41:11 UTC
Looks like device pass-through is just a victim here. When using the standard vga device, 16MB of memory is setup for VBE at fixed address 0xe0000000. The guest kernel knows nothing about this, so tries to assign device resources overlapping this range when the 82576 VF is hot added. When the range is passed into the KVM ioctl, it fails since the range has already been assigned to a different slot, causing the VM to exit. For the moment, there are several potential workarounds: 1. Add the option memmap=16M$0xe0000000 to the guest command line. This forces the guest to treat that range as reserved. 2. Use -vga cirrus rather than std. 3. Boot with less memory in the guest, effectively making the I/O window larger, allowing the guest to map the hotplug device below 0xe0000000. TODO: backport http://patchwork.ozlabs.org/patch/67919/ + friends vgabios needs an update too. Committed upstream: http://git.qemu.org/qemu.git/commit/?id=543f8e3468e6df32bfde8f84ac36d05a7604e082 http://git.qemu.org/qemu.git/commit/?id=4eccfec4943db1106c79a01069e18dd4f463219b Additional fix needed for migration compatibility: http://patchwork.ozlabs.org/patch/71545/ That puts the lfb @ 0xe0000000 back for older qemu versions. We will have to do the same for -M rhel6.0.0 as we can't just zap the mapping while the guest might use it. Only for -M rhel6.1.0+ we can really kill it. So we might additionally backport the e820 bits? Alex? Jes? Opinions? Ignore Comment #13. According to Comment #12, this bug has been fixed. Moving Status to VERIFIED. with vgabios-0.6b-3.5.el6.noarch.rpm installed, boot a guest and issue lspci -vs2: 00:02.0 VGA compatible controller: Technical Corp. Device 1111 (prog-if 00 [VGA controller]) Subsystem: Red Hat, Inc Device 1100 Physical Slot: 2 Flags: fast devsel Memory at f0000000 (32-bit, prefetchable) [size=16M] Expansion ROM at f1000000 [disabled] [size=64K] Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: see bug 654639 Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -see bug 654639+Previously, when a pass-through device was plugged into an operational guest on qemu-kvn, the process failed with "create_userspace_phys_mem: File exists. assigned_dev_iomem_map: Error: create new mapping failed" error. This error occurred because qemu-kvn attempted to use the memory address 0xe0000000, which was reserved for another process. This is now fixed and qemu-kvn no longer attempts to use the reserved memory at the location 0xe0000000. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0534.html An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0534.html |