From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xf6I8-0004I1-AT for qemu-devel@nongnu.org; Fri, 17 Oct 2014 08:06:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xf6I2-0000mB-6R for qemu-devel@nongnu.org; Fri, 17 Oct 2014 08:05:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34531) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xf6I1-0000m2-VU for qemu-devel@nongnu.org; Fri, 17 Oct 2014 08:05:50 -0400 Message-ID: <5441060D.6080904@redhat.com> Date: Fri, 17 Oct 2014 14:05:33 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1413254164-6320-1-git-send-email-zhuyijun@huawei.com> <543CB03E.3090902@redhat.com> <543D198D.7060203@redhat.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH] hw/arm/virt: Replace memory_region_init_ram with memory_region_allocate_system_memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , hangaohuai@huawei.com, peter.huangpeng@huawei.com, zhuyijun 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