[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qemu-s390x] [PATCH v1 5/5] s390: do not call memory_region_allocate
From: |
Christian Borntraeger |
Subject: |
Re: [qemu-s390x] [PATCH v1 5/5] s390: do not call memory_region_allocate_system_memory() multiple times |
Date: |
Tue, 16 Apr 2019 13:09:08 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
This fails with more than 8TB, e.g. "-m 9T "
[pid 231065] ioctl(10, KVM_SET_USER_MEMORY_REGION, {slot=0, flags=0,
guest_phys_addr=0, memory_size=0, userspace_addr=0x3ffc8500000}) = 0
[pid 231065] ioctl(10, KVM_SET_USER_MEMORY_REGION, {slot=0, flags=0,
guest_phys_addr=0, memory_size=9895604649984, userspace_addr=0x3ffc8500000}) =
-1 EINVAL (Invalid argument)
seems that the 2nd memslot gets the full size (and not 9TB-size of first slot).
On 15.04.19 15:27, Igor Mammedov wrote:
> s390 was trying to solve limited memslot size issue by abusing
> memory_region_allocate_system_memory(), which breaks API contract
> where the function might be called only once.
>
> s390 should have used memory aliases to fragment inital memory into
> smaller chunks to satisfy KVM's memslot limitation. But its a bit
> late now, since allocated pieces are transfered in migration stream
> separately, so it's not possible to just replace broken layout with
> correct one. Previous patch made MemoryRegion alases migratable and
> this patch switches to use them to split big initial RAM chunk into
> smaller pieces up to KVM_SLOT_MAX_BYTES each and registers aliases
> for migration.
>
> Signed-off-by: Igor Mammedov <address@hidden>
> ---
> A don't have access to a suitable system to test it, so I've simulated
> it with smaller chunks on x84 host. Ping-pong migration between old
> and new QEMU worked fine. KVM part should be fine as memslots
> using mapped MemoryRegions (in this case it would be aliases) as
> far as I know but is someone could test it on big enough host it
> would be nice.
> ---
> hw/s390x/s390-virtio-ccw.c | 20 +++++++++++++++-----
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index d11069b..12ca3a9 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -161,20 +161,30 @@ static void virtio_ccw_register_hcalls(void)
> static void s390_memory_init(ram_addr_t mem_size)
> {
> MemoryRegion *sysmem = get_system_memory();
> + MemoryRegion *ram = g_new(MemoryRegion, 1);
> ram_addr_t chunk, offset = 0;
> unsigned int number = 0;
> gchar *name;
>
> /* allocate RAM for core */
> + memory_region_allocate_system_memory(ram, NULL, "s390.whole.ram",
> mem_size);
> + /*
> + * memory_region_allocate_system_memory() registers allocated RAM for
> + * migration, however for compat reasons the RAM should be passed over
> + * as RAMBlocks of the size upto KVM_SLOT_MAX_BYTES. So unregister just
> + * allocated RAM so it won't be migrated directly. Aliases will take
> + * of segmenting RAM into legacy chunks.
> + */
> + vmstate_unregister_ram(ram, NULL);
> name = g_strdup_printf("s390.ram");
> while (mem_size) {
> - MemoryRegion *ram = g_new(MemoryRegion, 1);
> - uint64_t size = mem_size;
> + MemoryRegion *alias = g_new(MemoryRegion, 1);
>
> /* KVM does not allow memslots >= 8 TB */
> - chunk = MIN(size, KVM_SLOT_MAX_BYTES);
> - memory_region_allocate_system_memory(ram, NULL, name, chunk);
> - memory_region_add_subregion(sysmem, offset, ram);
> + chunk = MIN(mem_size, KVM_SLOT_MAX_BYTES);
> + memory_region_init_alias(alias, NULL, name, ram, offset, chunk);
> + vmstate_register_ram_global(alias);
> + memory_region_add_subregion(sysmem, offset, alias);
> mem_size -= chunk;
> offset += chunk;
> g_free(name);
>
- [qemu-s390x] [PATCH v1 1/5] sparc64: use memory_region_allocate_system_memory() only for '-m' specified RAM, (continued)
- [qemu-s390x] [PATCH v1 1/5] sparc64: use memory_region_allocate_system_memory() only for '-m' specified RAM, Igor Mammedov, 2019/04/15
- [qemu-s390x] [PATCH v1 2/5] ppc: rs6000_mc: drop usage of memory_region_allocate_system_memory(), Igor Mammedov, 2019/04/15
- [qemu-s390x] [PATCH v1 3/5] hppa: drop usage of memory_region_allocate_system_memory() for ROM, Igor Mammedov, 2019/04/15
- [qemu-s390x] [PATCH v1 4/5] memory: make MemoryRegion alias migratable, Igor Mammedov, 2019/04/15
- [qemu-s390x] [PATCH v1 5/5] s390: do not call memory_region_allocate_system_memory() multiple times, Igor Mammedov, 2019/04/15
- Re: [qemu-s390x] [PATCH v1 5/5] s390: do not call memory_region_allocate_system_memory() multiple times, Christian Borntraeger, 2019/04/16
- Re: [qemu-s390x] [PATCH v1 5/5] s390: do not call memory_region_allocate_system_memory() multiple times,
Christian Borntraeger <=
- Re: [qemu-s390x] [Qemu-devel] [PATCH v1 5/5] s390: do not call memory_region_allocate_system_memory() multiple times, Igor Mammedov, 2019/04/17
- Re: [qemu-s390x] [Qemu-devel] [PATCH v1 5/5] s390: do not call memory_region_allocate_system_memory() multiple times, Igor Mammedov, 2019/04/18
- Re: [qemu-s390x] [Qemu-devel] [PATCH v1 5/5] s390: do not call memory_region_allocate_system_memory() multiple times, David Hildenbrand, 2019/04/18
- Re: [qemu-s390x] [Qemu-devel] [PATCH v1 5/5] s390: do not call memory_region_allocate_system_memory() multiple times, Igor Mammedov, 2019/04/18
- Re: [qemu-s390x] [Qemu-devel] [PATCH v1 5/5] s390: do not call memory_region_allocate_system_memory() multiple times, David Hildenbrand, 2019/04/18
- Re: [qemu-s390x] [Qemu-devel] [PATCH v1 5/5] s390: do not call memory_region_allocate_system_memory() multiple times, Igor Mammedov, 2019/04/18
- Re: [qemu-s390x] [Qemu-devel] [PATCH v1 5/5] s390: do not call memory_region_allocate_system_memory() multiple times, David Hildenbrand, 2019/04/18