From: David Hildenbrand <david@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>, qemu-devel@nongnu.org
Cc: pbonzini@redhat.com, qemu-s390x@nongnu.org, dgilbert@redhat.com
Subject: Re: [Qemu-devel] [qemu-s390x] [PATCH RFC 0/2] s390: stop abusing memory_region_allocate_system_memory()
Date: Fri, 2 Aug 2019 10:26:19 +0200 [thread overview]
Message-ID: <cb35c294-1c2e-c40a-875f-77e018c4b344@redhat.com> (raw)
In-Reply-To: <0e9cd550-c69b-3e97-4619-6746da4d4bd1@redhat.com>
On 02.08.19 10:04, David Hildenbrand wrote:
> On 29.07.19 16:52, Igor Mammedov wrote:
>> While looking into unifying guest RAM allocation to use hostmem backends
>> for initial RAM (especially when -mempath is used) and retiring
>> memory_region_allocate_system_memory() API, leaving only single hostmem backend,
>> I was inspecting how currently it is used by boards and it turns out several
>> boards abuse it by calling the function several times (despite documented contract
>> forbiding it).
>>
>> s390 is one of such boards where KVM limitation on memslot size got propagated
>> to board design and memory_region_allocate_system_memory() was abused to satisfy
>> KVM requirement for max RAM chunk where memory region alias would suffice.
>>
>> Unfortunately, memory_region_allocate_system_memory() usage created migration
>> dependency where guest RAM is transferred in migration stream as several RAMBlocks
>> if it's more than KVM_SLOT_MAX_BYTES.
>
> So if I understand it correctly, we only call
> memory_region_allocate_system_memory() in case the guest initial memory
> size exceeds KVM_SLOT_MAX_BYTES - ~8TB.
(to clarify, I meant: call it more than once)
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2019-08-02 8:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-29 14:52 [Qemu-devel] [PATCH RFC 0/2] s390: stop abusing memory_region_allocate_system_memory() Igor Mammedov
2019-07-29 14:52 ` [Qemu-devel] [PATCH RFC 1/2] memory: make MemoryRegion alias migratable Igor Mammedov
2019-07-29 17:53 ` Dr. David Alan Gilbert
2019-07-30 13:25 ` Igor Mammedov
2019-07-30 13:34 ` Paolo Bonzini
2019-07-30 14:35 ` Igor Mammedov
2019-07-30 15:41 ` Dr. David Alan Gilbert
2019-07-29 14:52 ` [Qemu-devel] [PATCH RFC 2/2] s390: do not call memory_region_allocate_system_memory() multiple times Igor Mammedov
2019-07-29 14:58 ` [Qemu-devel] [PATCH RFC 0/2] s390: stop abusing memory_region_allocate_system_memory() Cornelia Huck
2019-07-30 15:22 ` [Qemu-devel] [qemu-s390x] " Christian Borntraeger
2019-07-30 15:49 ` Igor Mammedov
2019-08-02 8:04 ` David Hildenbrand
2019-08-02 8:23 ` David Hildenbrand
2019-08-02 8:26 ` David Hildenbrand [this message]
2019-08-02 8:29 ` Christian Borntraeger
2019-08-02 8:37 ` David Hildenbrand
2019-08-02 10:24 ` Christian Borntraeger
2019-08-02 9:18 ` Igor Mammedov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cb35c294-1c2e-c40a-875f-77e018c4b344@redhat.com \
--to=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).