On Wed, Oct 28, 2026 at 09:47:43AM +0000, Daniel P. Berrangé wrote:
On Wed, Oct 28, 2026 at 08:32:20AM +0100, Philippe Mathieu-Daudé wrote:
(Cc'ing migration compat and libvirt teams)
On 28/10/26 02:01, Richard Henderson wrote:
On 10/27/26 14:23, Philippe Mathieu-Daudé wrote:
'debug-threads' option for -name was deprecated in v11.0 (commit 1b65aeed2a0 "system: unconditionally enable thread naming") thus can now be removed.
Signed-off-by: Philippe Mathieu-Daudé<philmd@oss.qualcomm.com> Reviewed-by: Pierrick Bouvier<pierrick.bouvier@oss.qualcomm.com> Reviewed-by: Ján Tomko<jtomko@redhat.com> Reviewed-by: Dr. David Alan Gilbert<dave@treblig.org> Message-Id:<20261018232917.7716-1-philmd@oss.qualcomm.com> --- docs/about/deprecated.rst | 7 ------- docs/about/removed-features.rst | 9 +++++++-- system/vl.c | 11 ----------- tests/qtest/migration/framework.c | 4 ++-- tests/qtest/migration/precopy-tests.c | 2 +- qemu-options.hx | 7 +++---- 6 files changed, 13 insertions(+), 27 deletions(-)
You need to remove this from the testsuite as well:
Hmm I was surprised because the pipeline in my fork passed, but then looking clearer this job is marked as "allow_failure: true" for me, why is it blocking on the mainstream repo?
It isn't blocking on upstream repo, it is allow_failure: true there too. Manual inspection of the job shows it is a real bug though.
Back to the test, this is the migration-compat-x86_64 job running previous release binary vs latest one, so I'd think this is the expected behavior, v11.0 and v11.1 have that deprecated option, and we can not test vs v11.2 which removed it.
If we want to change that workflow, then when deprecating on v11.0 we also need to remove the tests coverage, so when we remove the feature at $deprecation_release+2 the migration-compat test does not break. Here the question is, do we want to keep testing deprecated features? Maybe yes in the case of unmaintained area when the deprecation process triggers new maintainers stepping in and the deprecation to be cancelled.
We could also mark the feature removed but keep it ignored and undocumented until the next release but we'll likely forget and miss that in workflow so I don't recommend that way.
Maybe there are another ways to resolve that but I'm not seeing them. Ideas?
'debug-threads=on' has no relationship to live migration data stream, it merely gives the threads names. Just remove this option from the migration testsuite as it is irrelevant to what is being tested.
We're testing with the old migration-test for compat, so Phil doesn't have an easy way to remove that part: .migration-compat-common: ... # Use the migration-tests from the older QEMU tree. This avoids # testing an old QEMU against new features/tests that it is not # compatible with. - cd build-previous Intentional to avoid new things not working with old QEMU binaries, but then this will be the case things break if we don't have protection of 2-release deprecation (where we could have removed the usage in test cases 2 releases in advance too when deprecating). At least two options I see: (1) for this release, we lose compat protection, we'll need to manually guard it, or (2) we provide some way to script/patch on top of the build-previous/ build before it builds, in this case we only need to remove the string in that test alone. I prefer (2) but I'd apologize in advance I don't have almost any time upstream before forum (replied this one only because I want to raise the point of using old test, in case Fabiano's already in PTO), I'm not sure if someone thinks it worthwhile. Thanks, -- Peter Xu