On Thu, 16 Jan 2020 11:42:09 +0100
Michal Privoznik <mprivozn(a)redhat.com> wrote:
> On 1/15/20 5:52 PM, Igor Mammedov wrote:
>> On Wed, 15 Jan 2020 16:34:53 +0100
>> Peter Krempa <pkrempa(a)redhat.com> wrote:
>>
>>> On Wed, Jan 15, 2020 at 16:07:37 +0100, Igor Mammedov wrote:
>>>> Deprecation period is ran out and it's a time to flip the switch
>>>> introduced by cd5ff8333a.
>>>> Disable legacy option for new machine types and amend documentation.
>>>>
>>>> Signed-off-by: Igor Mammedov <imammedo(a)redhat.com>
>>>> ---
>>>> CC: peter.maydell(a)linaro.org
>>>> CC: ehabkost(a)redhat.com
>>>> CC: marcel.apfelbaum(a)gmail.com
>>>> CC: mst(a)redhat.com
>>>> CC: pbonzini(a)redhat.com
>>>> CC: rth(a)twiddle.net
>>>> CC: david(a)gibson.dropbear.id.au
>>>> CC: libvir-list(a)redhat.com
>>>> CC: qemu-arm(a)nongnu.org
>>>> CC: qemu-ppc(a)nongnu.org
>>>> ---
>>>> hw/arm/virt.c | 2 +-
>>>> hw/core/numa.c | 6 ++++++
>>>> hw/i386/pc.c | 1 -
>>>> hw/i386/pc_piix.c | 1 +
>>>> hw/i386/pc_q35.c | 1 +
>>>> hw/ppc/spapr.c | 2 +-
>>>> qemu-deprecated.texi | 16 ----------------
>>>> qemu-options.hx | 8 ++++----
>>>> 8 files changed, 14 insertions(+), 23 deletions(-)
>>>
>>> I'm afraid nobody bothered to fix it yet:
>>>
>>>
https://bugzilla.redhat.com/show_bug.cgi?id=1783355
>>
>> It's time to start working on it :)
>> (looks like just deprecating stuff isn't sufficient motivation,
>> maybe actual switch flipping would work out better)
>>
>
> So how was the upgrade from older to newer version resolved? I mean, if
> the old qemu used -numa node,mem=XXX and it is migrated to a host with
> newer qemu, the cmd line can't be switched to -numa node,memdev=node0,
> can it? I'm asking because I've just started working on this.
see commit cd5ff8333a3c87 for detailed info.
Short answer is it's not really resolved [*],
-numa node,mem will keep working on newer QEMU but only for old machine types
new machine types will accept only -numa node,memdev.
One can check if "mem=' is supported by using QAPI query-machines
and checking numa-mem-supported field. That field is flipped to false
for 5.0 and later machine types in this patch.
Alright, so what we can do is the following:
1) For new machine types (pc-5.0/q35-5.0 and newer) use memdev= always.
2) For older machine types, we are stuck with mem= until qemu is capable
of migrating from mem= to memdev=
I think this is a safe thing to do since migrating from one version of a
machine type to another is not supported (since it can change guest
ABI). And we will see how much 2) bothers us. Does this sound reasonable?
Michal