diff options
author | Zhuang Yanying <ann.zhuangyanying@huawei.com> | 2016-11-17 20:31:03 +0800 |
---|---|---|
committer | Michael S. Tsirkin <mst@redhat.com> | 2016-11-18 17:29:34 +0200 |
commit | be4e0d737527d8670dc271712faae0de6a181b4e (patch) | |
tree | 5dbc85c11f98abcf3e4742c1977a67cc0ee0d890 /ui | |
parent | 83d768b5640946b7da55ce8335509df297e2c7cd (diff) | |
download | qemu-be4e0d737527d8670dc271712faae0de6a181b4e.zip qemu-be4e0d737527d8670dc271712faae0de6a181b4e.tar.gz qemu-be4e0d737527d8670dc271712faae0de6a181b4e.tar.bz2 |
ivshmem: Fix 64 bit memory bar configuration
Device ivshmem property use64=0 is designed to make the device
expose a 32 bit shared memory BAR instead of 64 bit one. The
default is a 64 bit BAR, except pc-1.2 and older retain a 32 bit
BAR. A 32 bit BAR can support only up to 1 GiB of shared memory.
This worked as designed until commit 5400c02 accidentally flipped
its sense: since then, we misinterpret use64=0 as use64=1 and vice
versa. Worse, the default got flipped as well. Devices
ivshmem-plain and ivshmem-doorbell are not affected.
Fix by restoring the test of IVShmemState member not_legacy_32bit
that got messed up in commit 5400c02. Also update its
initialization for devices ivhsmem-plain and ivshmem-doorbell.
Without that, they'd regress to 32 bit BARs.
Cc: qemu-stable@nongnu.org
Signed-off-by: Zhuang Yanying <ann.zhuangyanying@huawei.com>
Reviewed-by: Gonglei <arei.gonglei@huawei.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Diffstat (limited to 'ui')
0 files changed, 0 insertions, 0 deletions