On 28.03.19 01:24, David Gibson wrote: > On Wed, Mar 27, 2019 at 09:06:53PM +0100, David Hildenbrand wrote: >> On 27.03.19 17:45, Igor Mammedov wrote: >>> On Wed, 27 Mar 2019 14:59:44 +0100 >>> David Hildenbrand <[email protected]> wrote: >>> >>>> Right now we configure the pagesize quite early, when initializing KVM. >>>> This is long before system memory is actually allocated via >>>> memory_region_allocate_system_memory(), and therefore memory backends >>>> marked as mapped. >>>> >>>> Instead, let's configure the maximum page size after initializing >>>> memory in s390_memory_init(). cap_hpage_1m is still properly >>>> configured before creating any CPUs, and therefore before configuring >>>> the CPU model and eventually enabling CMMA. >>>> >>>> We might later want to replace qemu_getrampagesize() by another >>>> detection mechanism, e.g. only looking at mapped, initial memory. >>>> We don't support any memory devices yet, and if so, we can always reject >>>> devices with a page size bigger than the initial page size when >>>> hotplugging. qemu_getrampagesize() should work for now, especially when >>>> converting it to only look at mapped backends. >>>> >>>> Signed-off-by: David Hildenbrand <[email protected]> >>> >>> Acked-by: Igor Mammedov <[email protected]> >> >> BTW, do we want >> >> qemu_getmaxrampagesize() >> qemu_getminrampagesize() > > That could work. > >> or similar. qemu_getrampagesize() in its current form is really far from >> beautiful. > > Yeah, and AFAICT the way it's used here remains incorrect. >
Soooooo, this is all a big mess :) 1. We have to decide on the page size before initializing the CPU model (due to CMMA) and before creating any CPUs -> We have to do it early/before machine init. 2. Memory devices (if ever supported) are created + realized (+ backends mapped) after machine init. 3. Memory backends are created delayed, so even after creating devices. All we can do for s390x is a) Use the page size of initial memory when configuring the page size in KVM. (AFAICS what would be done right now) b) When cold/hotplugging memory devices, reject devices with a page size bigger than the page size of initial memory. Not an issue now. In the future it might be "unfortunate" but at least we can print a nice error from the machine hotplug handler "page size not supported in this configuration". I double checked, "-numa" is not supported in s390x. So "-numa node,mempath=..." does not apply. However this might change and we can easily forget about this. Also, getting rid of -mem-path might be one issue. So the right think to do would be a) this patch b) introduce and use qemu_getmaxrampagesize() Then, we would properly detect the maximum page size *for initial memory*. Memory devices, we will have to worry about in the future, but should be easy to handle (remember and check against maximum configured page size). Thoughts? -- Thanks, David / dhildenb
