| Message ID | 158514992409.478799.6718223069768660390.stgit@bahia.lan (mailing list archive) |
|---|---|
| Headers | show |
| Series | spapr: Get rid of CAS reboot flag | expand |
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. >
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().
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.
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(-)