The simply said "its dependencies" seems to be a dependency hell.
  72fdd4de8e5 spapr: register dummy ICPs later
referred to fix patch:
  72194664c8a1 spapr: use spapr->vsmt to compute VCPU ids
is not in Qemu 2.11, nor is the one this fixes
  8904e5a75005 spapr: Adjust default VSMT value for better migration 
compatibility


Without testing it seems we would need:
- ? marks part of the series I'm unsure it is a hard requirement but it seems 
entangled enough vsmt/vcpuid to consider it as well to not break functionality 
:-/
- f#<num> marks which other change it fixes (implicit depends)
- r#<num> marks which other change depends on it

#1  ? r#2    1a5008fc spapr: harden code that depends on VSMT
#2    f#7    72fdd4de spapr: register dummy ICPs later
#3  ? f#4    b1a568c1 spapr: fix missing CPU core nodes in DT when running with 
TCG
#4  ?        5d0fb150 spapr: consolidate the VCPU id numbering logic in a 
single place
#5  ?        14bb4486 rename spapr_vcpu_id() to spapr_get_vcpu_id()
#6  ?        648edb64 spapr: move VCPU calculation to core machine code
#7    f#9    72194664 spapr: use spapr->vsmt to compute VCPU ids
#8    f#9    4ad64cbd spapr: set vsmt to MAX(8, smp_threads)
#9    f#2.11 8904e5a7 spapr: Adjust default VSMT value for better migration 
compatibility
#10   r#9    1f20f2e0 spapr: Allow some cases where we can't set VSMT mode in 
the kernel

#1 has too much noise and isn't  a hard requirement, so I skipped it
There also was some noise for:
- max_vthreads being renamed
- on #7 for threads[0]
- on #6 for POWERPC_CPU
- on #6 for spapr_caps_pre_load
but that was ok.

Overall backport in packaged format would be:
- 
https://git.launchpad.net/~paelzer/ubuntu/+source/qemu/commit/?id=416b00af3a8bbfc26094c4a3eba0bce09888af6c
- 
https://git.launchpad.net/~paelzer/ubuntu/+source/qemu/commit/?id=0c93d6500d13e9eeefcf8797e0f05e0225bf9438

I made it part of the ppa that was open for bug 1762854 - so you can test both 
at once.
=> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3233

So it seems doable, but it is quite a huge change still.
9 patches with overall:
 hw/ppc/spapr.c          |  160 ++++++++++++++++++++++++++++++------------------
 hw/ppc/spapr_cpu_core.c |    9 --
 include/hw/ppc/spapr.h  |    3

OTOH it is ppc64 only so it is your (=IBM) call to make, do you want to use the 
backport or do you think there is a much smaller fix (changing 1-5 lines 
somewhere) for qemu 2.11 available to "fix just the issue"?
This is a tradeoff, if it becomes too complex then the backport is clearly 
preferred, but if there would be a way to just handle this more comprehensively 
without introducing all the new VSMT handling first let me know.

TL;DR I'd ask you to:
- evaluate if a (much) simpler fix would be available
- if not please review the backport to fit your needs
- also then verify the ppa provided so that we can go forward

Setting status to incomplete as I wait for feedback on that.

** Changed in: qemu (Ubuntu)
       Status: Triaged => Incomplete

** Changed in: ubuntu-power-systems
       Status: Triaged => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1763468

Title:
  [Ubuntu 18.04] P8 compat mode migration fails for Ubuntu 16.04.4 P8
  Guest from Ubuntu 16.04.4 P8 Host -> Ubuntu 18.04 P9 Host

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1763468/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to