The CAS reboot flag was introduced in QEMU 2.10 to allow the guest
to be presented a new boot-time device tree after CAS negotiation.
CAS-generated resets rely on qemu_system_reset_request() which has
the particularity of dropping the main loop lock at some point. This
opens a window where migration can happen, hence promotting the CAS
reboot flag to actual state that we should also migrate. In practice,
this can't happen anymore since we have eliminated the scenario of
the XICS/XIVE switch and the much less frequent scenario of device
plug/unplug before CAS.

We still have much of the CAS reboot bits around though. The full FDT
rendering we do at CAS is enough to get rid of them once and far all.

Some preliminary cleanup is made before going for the full removal,
for easier reviewing. At some point I had the need to move some code
around in CAS, and Alexey's patch from the "spapr: kill SLOF" (v8)
series proved to be helpful so I've reused it in this patchset.

This series applies cleanly on both ppc-for-5.0 and ppc-for-5.1.
Since it doesn't fix any actual bug, I think this can be delayed
to 5.1.

--
Greg

---

Alexey Kardashevskiy (1):
      spapr/cas: Separate CAS handling from rebuilding the FDT

Greg Kurz (3):
      spapr: Don't check capabilities removed between CAS calls
      spapr: Simplify selection of radix/hash during CAS
      spapr: Drop CAS reboot flag


 hw/ppc/spapr.c         |   20 ++-------
 hw/ppc/spapr_hcall.c   |  108 +++++++++++++++++++++++-------------------------
 include/hw/ppc/spapr.h |    8 +++-
 3 files changed, 63 insertions(+), 73 deletions(-)

On Wed, Mar 25, 2020 at 04:25:24PM +0100, Greg Kurz wrote:
> The CAS reboot flag was introduced in QEMU 2.10 to allow the guest
> to be presented a new boot-time device tree after CAS negotiation.
> CAS-generated resets rely on qemu_system_reset_request() which has
> the particularity of dropping the main loop lock at some point. This
> opens a window where migration can happen, hence promotting the CAS
> reboot flag to actual state that we should also migrate. In practice,
> this can't happen anymore since we have eliminated the scenario of
> the XICS/XIVE switch and the much less frequent scenario of device
> plug/unplug before CAS.
> 
> We still have much of the CAS reboot bits around though. The full FDT
> rendering we do at CAS is enough to get rid of them once and far all.
> 
> Some preliminary cleanup is made before going for the full removal,
> for easier reviewing. At some point I had the need to move some code
> around in CAS, and Alexey's patch from the "spapr: kill SLOF" (v8)
> series proved to be helpful so I've reused it in this patchset.
> 
> This series applies cleanly on both ppc-for-5.0 and ppc-for-5.1.
> Since it doesn't fix any actual bug, I think this can be delayed
> to 5.1.

Applied to ppc-for-5.1.

> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

On 31/03/2020 11:44, David Gibson wrote:
> On Wed, Mar 25, 2020 at 04:25:24PM +0100, Greg Kurz wrote:
>> The CAS reboot flag was introduced in QEMU 2.10 to allow the guest
>> to be presented a new boot-time device tree after CAS negotiation.
>> CAS-generated resets rely on qemu_system_reset_request() which has
>> the particularity of dropping the main loop lock at some point. This
>> opens a window where migration can happen, hence promotting the CAS
>> reboot flag to actual state that we should also migrate. In practice,
>> this can't happen anymore since we have eliminated the scenario of
>> the XICS/XIVE switch and the much less frequent scenario of device
>> plug/unplug before CAS.
>>
>> We still have much of the CAS reboot bits around though. The full FDT
>> rendering we do at CAS is enough to get rid of them once and far all.
>>
>> Some preliminary cleanup is made before going for the full removal,
>> for easier reviewing. At some point I had the need to move some code
>> around in CAS, and Alexey's patch from the "spapr: kill SLOF" (v8)
>> series proved to be helpful so I've reused it in this patchset.
>>
>> This series applies cleanly on both ppc-for-5.0 and ppc-for-5.1.
>> Since it doesn't fix any actual bug, I think this can be delayed
>> to 5.1.
> 
> Applied to ppc-for-5.1.



Can you push it out please? The existing ppc-for-5.1 corrupts stack on
my machine in qemu_init().

-- 
Alexey

On Tue, 31 Mar 2020 13:59:01 +1100
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:

> 
> 
> On 31/03/2020 11:44, David Gibson wrote:
> > On Wed, Mar 25, 2020 at 04:25:24PM +0100, Greg Kurz wrote:
> >> The CAS reboot flag was introduced in QEMU 2.10 to allow the guest
> >> to be presented a new boot-time device tree after CAS negotiation.
> >> CAS-generated resets rely on qemu_system_reset_request() which has
> >> the particularity of dropping the main loop lock at some point. This
> >> opens a window where migration can happen, hence promotting the CAS
> >> reboot flag to actual state that we should also migrate. In practice,
> >> this can't happen anymore since we have eliminated the scenario of
> >> the XICS/XIVE switch and the much less frequent scenario of device
> >> plug/unplug before CAS.
> >>
> >> We still have much of the CAS reboot bits around though. The full FDT
> >> rendering we do at CAS is enough to get rid of them once and far all.
> >>
> >> Some preliminary cleanup is made before going for the full removal,
> >> for easier reviewing. At some point I had the need to move some code
> >> around in CAS, and Alexey's patch from the "spapr: kill SLOF" (v8)
> >> series proved to be helpful so I've reused it in this patchset.
> >>
> >> This series applies cleanly on both ppc-for-5.0 and ppc-for-5.1.
> >> Since it doesn't fix any actual bug, I think this can be delayed
> >> to 5.1.
> > 
> > Applied to ppc-for-5.1.
> 
> 
> 
> Can you push it out please? The existing ppc-for-5.1 corrupts stack on
> my machine in qemu_init().
> 

Can you provide more details ?

On 31/03/2020 18:08, Greg Kurz wrote:
> On Tue, 31 Mar 2020 13:59:01 +1100
> Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> 
>>
>>
>> On 31/03/2020 11:44, David Gibson wrote:
>>> On Wed, Mar 25, 2020 at 04:25:24PM +0100, Greg Kurz wrote:
>>>> The CAS reboot flag was introduced in QEMU 2.10 to allow the guest
>>>> to be presented a new boot-time device tree after CAS negotiation.
>>>> CAS-generated resets rely on qemu_system_reset_request() which has
>>>> the particularity of dropping the main loop lock at some point. This
>>>> opens a window where migration can happen, hence promotting the CAS
>>>> reboot flag to actual state that we should also migrate. In practice,
>>>> this can't happen anymore since we have eliminated the scenario of
>>>> the XICS/XIVE switch and the much less frequent scenario of device
>>>> plug/unplug before CAS.
>>>>
>>>> We still have much of the CAS reboot bits around though. The full FDT
>>>> rendering we do at CAS is enough to get rid of them once and far all.
>>>>
>>>> Some preliminary cleanup is made before going for the full removal,
>>>> for easier reviewing. At some point I had the need to move some code
>>>> around in CAS, and Alexey's patch from the "spapr: kill SLOF" (v8)
>>>> series proved to be helpful so I've reused it in this patchset.
>>>>
>>>> This series applies cleanly on both ppc-for-5.0 and ppc-for-5.1.
>>>> Since it doesn't fix any actual bug, I think this can be delayed
>>>> to 5.1.
>>>
>>> Applied to ppc-for-5.1.
>>
>>
>>
>> Can you push it out please? The existing ppc-for-5.1 corrupts stack on
>> my machine in qemu_init().
>>
> 
> Can you provide more details ?

This one:
6d15081ee3ca (HEAD, dwg/ppc-for-5.1) 4 hours ago Nicholas Piggin
ppc/pnv: Add support for NMI interface

removed {} in:


diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 671535ebe6a6..ac83b8698b8e 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -2067,6 +2067,7 @@ static const TypeInfo types[] = {
         .interfaces = (InterfaceInfo[]) {
             { TYPE_INTERRUPT_STATS_PROVIDER },
             { TYPE_NMI },
+            { },
         },


David fixed that up, pushed out (forced, as usual), all good, sorry for
the noise :) Cheers.


-- 
Alexey