On 1/16/20 1:37 PM, Igor Mammedov wrote:
On Thu, 16 Jan 2020 11:42:09 +0100 Michal Privoznik <mprivozn@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@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@redhat.com> --- CC: peter.maydell@linaro.org CC: ehabkost@redhat.com CC: marcel.apfelbaum@gmail.com CC: mst@redhat.com CC: pbonzini@redhat.com CC: rth@twiddle.net CC: david@gibson.dropbear.id.au CC: libvir-list@redhat.com CC: qemu-arm@nongnu.org CC: qemu-ppc@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:
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