qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] vl/s390: fixup ram sizes for compat machines


From: Cornelia Huck
Subject: Re: [PATCH v2] vl/s390: fixup ram sizes for compat machines
Date: Wed, 1 Apr 2020 13:12:43 +0200

On Wed, 1 Apr 2020 13:01:43 +0200
Christian Borntraeger <address@hidden> wrote:

> On 01.04.20 12:13, Cornelia Huck wrote:
> > On Wed,  1 Apr 2020 04:50:14 -0400
> > Christian Borntraeger <address@hidden> 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  
> > 
> > "to replace any unaligned -m value" ?
> >   
> >> aligned one or to use a machine version >= 5.0 as future versions might
> >> remove the compatibility handling.  
> > 
> > I'm confused by the second part of the sentence. Warning about possible
> > future removal of the compat stuff is fine, but I don't understand the
> > suggestion to use a machine type >= 5.0. If I create a new machine that
> > does not need be migrated to an old QEMU, using the latest machine type
> > always seems like the best idea, right? And for a migration target it's
> > not like we can choose the version freely anyway.  
> 
> 
> My point was that - when you redefine your guest, which is disruptive anyway
> you could also change the machine version to 5.0 and keep the strange memory
> size.

Ah, ok. That depends however on whether you still need compatibility,
so it might not be advisable. What about:

"...or to switch to a machine version >= 5.0 if migration to older
machine types is not needed; future versions might remove the
compatibility handling."

?




reply via email to

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