qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]