[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] hw/arm/virt: Replace memory_region_init_ram wit
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH] hw/arm/virt: Replace memory_region_init_ram with memory_region_allocate_system_memory |
Date: |
Fri, 17 Oct 2014 14:05:33 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 |
Il 14/10/2014 14:48, Peter Maydell ha scritto:
> Why don't we just do that automatically for all RAM regions
> the machine creates? We're already splitting up a contiguous
> chunk of RAM to parcel out to RAM regions, that's what the
> indirection through ramaddrs is all about.
I can think of one reason to not do this. If we just mmap-ed RAM
regions consecutively from a file, the offset in the file should be
aligned to the huge page size for "main" RAM region(s). For example,
assume gigabyte-sized huge pages; the offset for main RAM must be
gigabyte aligned. If the board creates 16MiB of VRAM first, and 2 GiB
of main RAM second, you will end up wasting 1024-16 MiB of RAM for VRAM.
This same waste happened before the introduction of
memory_region_allocate_system_memory, in fact.
Of course this could in principle be fixed by having boards create main
RAM first, but it would be an even more complicated change. You could
come up with a way of reserving ram_addr_t ranges, which would also help
hotplug; however, I am not sure if all architectures require the maximum
hotplugged memory size to be specified upfront.
Ultimately, if a RAM region other than main RAM has benefits from huge
pages, the device that creates it probably should have a memdev
property. This is not the case for any current device, except perhaps
ivshmem.
Paolo
Re: [Qemu-devel] [PATCH] hw/arm/virt: Replace memory_region_init_ram with memory_region_allocate_system_memory, Yijun Zhu, 2014/10/14