Re: [PATCH] ppc/spapr: Advertise StoreEOI for POWER10 compat guests

["Cédric Le Goater" <clg@kaod.org>]

>> Unfortunately, this patch breaks migration under TCG because the XIVE
>> source flag is not updated on the target side. KVM is not impacted
>> because the emulated sources are not used. This needs to be addressed
>> in a v2.
>>
>> That said, even without this patch, TCG migration is broken. some CPUs
>> on the receive side are stalled on CPU Hard LOCKUPs. QEMU 6.2 is impacted.
>> So it has been a while :/
> 
> Ouch. Guess we need to add TCG migration tests in the test workflow ...

Regarding the first issue with the new XIVE source flag, this routine
changes an object property after realize which is a no-no for migration :

     void spapr_xive_enable_store_eoi(SpaprXive *xive, bool enable)
     {
         if (enable) {
             xive->source.esb_flags |= XIVE_SRC_STORE_EOI;
         } else {
             xive->source.esb_flags &= ~XIVE_SRC_STORE_EOI;
         }
     }

I think we need a new SpaprXive state to represent the characteristic
of the source indirectly negotiated by CAS when the CPU is a POWER10.
we would use it to update xive->source.esb_flags at post_load time
after migration.

Or simply mimick CAS :

@@ -531,6 +531,14 @@ static int spapr_xive_post_load(SpaprInt
          return kvmppc_xive_post_load(xive, version_id);
      }
  
+    PowerPCCPU *first_ppc_cpu = POWERPC_CPU(first_cpu);
+    bool enable = ppc_check_compat(first_ppc_cpu, CPU_POWERPC_LOGICAL_3_10, 0,
+                                   first_ppc_cpu->compat_pvr);
+    spapr_xive_enable_store_eoi(xive, enable);
+
      return 0;
  }
  
which has the benefit of being stateless.

Ideas ?

Thanks,

C.