On Thu, 16 Jan 2020 14:03:12 +0100 Michal Privoznik <mprivozn@redhat.com> wrote:
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. it's not only x86, it's for all machines that support numa hence numa-mem-supported was introduced to make it easier for libvirt to figure out when to use which syntax.
The plan was to release libvirt with support for numa-mem-supported and then when newer QEMU forbids 'mem=' it change will be transparent for relatively fresh livirt. Whether it still does make sense though. We could go with your suggestion in which case libvirt unilaterally switches to using only 'memdev' for 5.0 machine types and then later (5.1..) we release QEMU that enforces it. In this case we can axe numa-mem-supported (I'd volunteer) to avoid supporting yet another ABI/smart logic where your way could be sufficient. Daniel, what's your take on Michal's approach?
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