| commit | 4d8938a05db15dea2c86c4ab9c5f872f160d2188 | |
| author | David Hildenbrand <david@redhat.com> | |
| Thu, 7 Jun 2018 15:47:04 +0000 (7 17:47 +0200) | ||
| committer | Paolo Bonzini <pbonzini@redhat.com> | |
| Thu, 28 Jun 2018 17:05:31 +0000 (28 19:05 +0200) | ||
| tree | 51ae26035da86e61cf247f471e63b3b234fb8fa1 | treesnapshot (tar.gz zip) |
| parent | 93d1499c8119989e3eb9a6936c5a18aaaaca6330 | commitdiff |
memory-device: turn alignment assert into check
The start of the address space indicates which maximum alignment is
supported by our machine (e.g. ppc, x86 1GB). This is helpful to
catch fragmenting guest physical memory in strange fashions.
Right now we can crash QEMU by e.g. (there might be easier examples)
qemu-system-x86_64 -m 256M,maxmem=20G,slots=2 \
-object memory-backend-file,id=mem0,size=8192M,mem-path=/dev/zero,align=8192M \
-device pc-dimm,id=dimm1,memdev=mem0
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20180607154705.6316-2-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The start of the address space indicates which maximum alignment is
supported by our machine (e.g. ppc, x86 1GB). This is helpful to
catch fragmenting guest physical memory in strange fashions.
Right now we can crash QEMU by e.g. (there might be easier examples)
qemu-system-x86_64 -m 256M,maxmem=20G,slots=2 \
-object memory-backend-file,id=mem0,size=8192M,mem-path=/dev/zero,align=8192M \
-device pc-dimm,id=dimm1,memdev=mem0
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20180607154705.6316-2-david@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
| hw/mem/memory-device.c | diffblobblamehistory |