diff options
| author | Yu Ning <yu.ning@intel.com> | 2018-01-12 18:22:35 +0800 |
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2018-02-13 11:44:13 +0100 |
| commit | 7a5235c9e679c58be41c7f0d2f4092ded8bd01f2 (patch) | |
| tree | 0c92f3550a57df5df589a7b87df0768ed66b3eec /block | |
| parent | 7b40951922616628d028622fed5aaeec63275201 (diff) | |
| download | qemu-7a5235c9e679c58be41c7f0d2f4092ded8bd01f2.zip qemu-7a5235c9e679c58be41c7f0d2f4092ded8bd01f2.tar.gz qemu-7a5235c9e679c58be41c7f0d2f4092ded8bd01f2.tar.bz2 | |
hax: Support guest RAM sizes of 4GB or more
Since HAX_VM_IOCTL_ALLOC_RAM takes a 32-bit size, it cannot handle
RAM blocks of 4GB or larger, which is why HAXM can only run guests
with less than 4GB of RAM. Solve this problem by utilizing the new
HAXM API, HAX_VM_IOCTL_ADD_RAMBLOCK, which takes a 64-bit size, to
register RAM blocks with the HAXM kernel module. The new API is
first added in HAXM 7.0.0, and its availablility and be confirmed
by the presence of the HAX_CAP_64BIT_RAMBLOCK capability flag.
When the guest RAM size reaches 7GB, QEMU will ask HAXM to set up a
memory mapping that covers a 4GB region, which will fail, because
HAX_VM_IOCTL_SET_RAM also takes a 32-bit size. Work around this
limitation by splitting the large mapping into small ones and
calling HAX_VM_IOCTL_SET_RAM multiple times.
Bug: https://bugs.launchpad.net/qemu/+bug/1735576
Signed-off-by: Yu Ning <yu.ning@intel.com>
Message-Id: <1515752555-12784-1-git-send-email-yu.ning@linux.intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'block')
0 files changed, 0 insertions, 0 deletions