On Tue, 31 Mar 2020 13:59:01 +1100 Alexey Kardashevskiy <a...@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 ?
