From: Cornelia Huck <cohuck@redhat.com>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: "Lukáš Doktor" <ldoktor@redhat.com>,
"Thomas Huth" <thuth@redhat.com>,
"Janosch Frank" <frankja@linux.ibm.com>,
"David Hildenbrand" <david@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
"Halil Pasic" <pasic@linux.ibm.com>,
qemu-s390x <qemu-s390x@nongnu.org>,
"Igor Mammedov" <imammedo@redhat.com>,
"Richard Henderson" <rth@twiddle.net>
Subject: Re: [PATCH v3 1/1] vl/s390x: fixup ram sizes for compat machines
Date: Thu, 2 Apr 2020 17:16:59 +0200 [thread overview]
Message-ID: <20200402171659.1ba57efc.cohuck@redhat.com> (raw)
In-Reply-To: <20200401123754.109602-1-borntraeger@de.ibm.com>
On Wed, 1 Apr 2020 08:37:54 -0400
Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> Older QEMU versions did fixup the ram size to match what can be reported
> via sclp. We need to mimic this behaviour for machine types 4.2 and
> older to not fail on inbound migration for memory sizes that do not fit.
> Old machines with proper aligned memory sizes are not affected.
>
> Alignment table:
> VM size (<=) | Alignment
> --------------------------
> 1020M | 1M
> 2040M | 2M
> 4080M | 4M
> 8160M | 8M
> 16320M | 16M
> 32640M | 32M
> 65280M | 64M
> 130560M | 128M
> 261120M | 256M
> 522240M | 512M
> 1044480M | 1G
> 2088960M | 2G
> 4177920M | 4G
> 8355840M | 8G
>
> Suggested action is to replace unaligned -m value with a suitable
> aligned one or if a change to a newer machine type is possible, use a
> machine version >= 5.0.
>
> A future versions might remove the compatibility handling.
s/versions/version/ (fixed it up)
>
> For machine types >= 5.0 we can simply use an increment size of 1M and
> use the full range of increment number which allows for all possible
> memory sizes. The old limitation of having a maximum of 1020 increments
> was added for standby memory, which we no longer support. With that we
> can now support even weird memory sizes like 10001234 MB.
>
> As we no longer fixup maxram_size as well, make other users use ram_size
> instead. Keep using maxram_size when setting the maximum ram size in KVM,
> as that will come in handy in the future when supporting memory hotplug
> (in contrast, storage keys and storage attributes for hotplugged memory
> will have to be migrated per RAM block in the future).
>
> Fixes: 3a12fc61af5c ("390x/s390-virtio-ccw: use memdev for RAM")
> Reported-by: Lukáš Doktor <ldoktor@redhat.com>
> Cc: Igor Mammedov <imammedo@redhat.com>
> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
> hw/s390x/s390-skeys.c | 2 +-
> hw/s390x/s390-stattrib-kvm.c | 4 ++--
> hw/s390x/s390-virtio-ccw.c | 21 +++++++++++++++++++++
> hw/s390x/sclp.c | 17 +++++------------
> include/hw/boards.h | 7 +++++++
> softmmu/vl.c | 3 +++
> 6 files changed, 39 insertions(+), 15 deletions(-)
Thanks, applied to s390-fixes (with the fixup message fixed up.)
[I plan to send a pull request for s390-fixes tomorrow, so please let
me know if there are any further concerns.]
prev parent reply other threads:[~2020-04-02 15:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-01 12:37 [PATCH v3 1/1] vl/s390x: fixup ram sizes for compat machines Christian Borntraeger
2020-04-01 12:46 ` Christian Borntraeger
2020-04-01 13:14 ` David Hildenbrand
2020-04-02 9:22 ` Cornelia Huck
2020-04-02 9:25 ` Christian Borntraeger
2020-04-02 10:27 ` Cornelia Huck
2020-04-02 10:32 ` Christian Borntraeger
2020-04-01 16:34 ` Igor Mammedov
2020-04-02 9:27 ` Cornelia Huck
2020-04-02 9:39 ` Christian Borntraeger
2020-04-02 9:43 ` Cornelia Huck
2020-04-02 11:25 ` Cornelia Huck
2020-04-02 11:32 ` Christian Borntraeger
2020-04-02 11:39 ` Igor Mammedov
2020-04-02 11:42 ` Christian Borntraeger
2020-04-02 12:05 ` Igor Mammedov
2020-04-02 12:09 ` Christian Borntraeger
2020-04-02 12:35 ` Christian Borntraeger
2020-04-02 14:18 ` Cornelia Huck
2020-04-02 15:01 ` Igor Mammedov
2020-04-02 17:48 ` Peter Xu
2020-04-02 15:16 ` Cornelia Huck [this message]
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=20200402171659.1ba57efc.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=david@redhat.com \
--cc=dgilbert@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=imammedo@redhat.com \
--cc=ldoktor@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=rth@twiddle.net \
--cc=thuth@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.