Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 743391 - KVM guest limited to 40bit of physical address space
KVM guest limited to 40bit of physical address space
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.2
All Linux
low Severity medium
: beta
: 6.1
Assigned To: Andrea Arcangeli
Virtualization Bugs
: Triaged
Depends On: 630975
Blocks: 580953 748554
  Show dependency treegraph
 
Reported: 2011-10-04 14:40 EDT by Andrea Arcangeli
Modified: 2013-01-09 19:25 EST (History)
16 users (show)

See Also:
Fixed In Version: qemu-kvm-0.12.1.2-2.198.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 630975
Environment:
Last Closed: 2011-12-06 11:05:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:1531 normal SHIPPED_LIVE Moderate: qemu-kvm security, bug fix, and enhancement update 2011-12-05 20:23:30 EST

  None (edit)
Comment 7 Eduardo Habkost 2011-10-28 14:01:17 EDT
Moving to ON_QA because Errata Tool did not do it
Comment 8 FuXiangChun 2011-10-31 04:46:49 EDT
reproduce on qemu-kvm-0.12.1.2-2.193.el6.x86_64 and
seabios-0.6.1.2-5.el6.x86_64 in 4T host

1. boot guest with >1T memory, guest will identify <1T memory.   

1.1. #/usr/libexec/qemu-kvm -M rhel6.2.0 -enable-kvm -m 1600G 

1.2 in guest,the memory is just 567G not 1.6T
#free -g
             total       used       free     shared    buffers     cached
Mem:           567          6        561          0          0          0
-/+ buffers/cache:          6        561
Swap:            3          0          3

2. boot guest with =1T memory, guest will identify 1T memory

2.1#/usr/libexec/qemu-kvm -M rhel6.2.0 -enable-kvm -m 1024G
2.1 in guest,the memory is 1T
# free -g
             total       used       free     shared    buffers     cached
Mem:          1009         10        999          0          0          0
-/+ buffers/cache:          9        999
Swap:            3          0          3



Tested with qemu-206 using rhel6.2-snap2 guest,the host RAM is 4T,I tested 2
conditions
1.boot guest with host free memory,guest can be booted successfully in 1-2 mins
with RAM=host free memory(3998G)
#qemu-kvm -m  -m 3998G  .....
#in guest
# free -g
             total       used       free     shared    buffers     cached
Mem:          3942         37       3905          0          0          0
-/+ buffers/cache:         37       3905
Swap:            3          0          3

2.boot guest with >= 4t,qemu-kvm will be aborted with dump
(gdb) bt
#0  0x0000003eea032885 in raise () from /lib64/libc.so.6
#1  0x0000003eea034065 in abort () from /lib64/libc.so.6
#2  0x0000000000484710 in qemu_memalign (alignment=2097152, size=4399120252928)
at osdep.c:112
#3  0x00000000004ecc52 in qemu_ram_alloc_from_ptr (dev=<value optimized out>,
name=<value optimized out>, size=4399120252928, host=<value optimized out>)
    at /usr/src/debug/qemu-kvm-0.12.1.2/exec.c:2730
#4  0x0000000000452863 in pc_init1 (ram_size=3758096384,
boot_device=0x7fffffffdfc0 "cad", kernel_filename=0x0, kernel_cmdline=0x642ee2
"", initrd_filename=0x0, 
    cpu_model=0x631d85 "cpu64-rhel6", pci_enabled=1) at
/usr/src/debug/qemu-kvm-0.12.1.2/hw/pc.c:1115
#5  0x000000000040d4ae in main (argc=<value optimized out>, argv=<value
optimized out>, envp=<value optimized out>) at
/usr/src/debug/qemu-kvm-0.12.1.2/vl.c:6254

2.1 swap size in host
 Swap:  2031608k total
Comment 9 juzhang 2011-10-31 04:51:58 EDT
Hi,Andrea

   The questions are as same as bz630975.
   According to comment8,would you please answer me two questions?
   1.if boot guest with >= 4t,qemu-kvm will be aborted with dump,it is
normal?as I knew,kvm quest support over-commit.for this case,the host RAM is
4T,if we boot guest is >=4T,the qemu-kvm will be aborted with dump.would you
please elaborate it?
   2.if question 1 problem is normal,according to our results,can we set this
issue as verified?

   thanks
Comment 14 juzhang 2011-11-02 23:48:19 EDT
According to comment8,I'm going to set this issue as verified.if you think comment9 question1 is a problem.please let us know.we will open new issue.
Comment 16 Dor Laor 2011-11-03 11:49:08 EDT
(In reply to comment #8)

> 2.boot guest with >= 4t,qemu-kvm will be aborted with dump
> (gdb) bt
> #0  0x0000003eea032885 in raise () from /lib64/libc.so.6



why > 4Tram?
Comment 17 juzhang 2011-11-04 00:59:38 EDT
(In reply to comment #16)
> (In reply to comment #8)
> 
> > 2.boot guest with >= 4t,qemu-kvm will be aborted with dump
> > (gdb) bt
> > #0  0x0000003eea032885 in raise () from /lib64/libc.so.6
> 
> 
> 
> why > 4Tram?
1.Boundary testing.for example,if we  max support 4T.as usual, we test it > 4T.see what happens.our expect result should be give more friendly actions instead of crash.
2.Actually,Just > host free memory not only > 4T will be crash.
Comment 20 errata-xmlrpc 2011-12-06 11:05:10 EST
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.

http://rhn.redhat.com/errata/RHSA-2011-1531.html

Note You need to log in before you can comment on or make changes to this bug.