Re: [PATCH 4/7] spapr: Fix record-replay machine reset consuming too many events

["Nicholas Piggin" <npiggin@gmail.com>]

On Tue Aug 8, 2023 at 1:52 PM AEST, Pavel Dovgalyuk wrote:
> On 08.08.2023 06:09, Nicholas Piggin wrote:
> > On Sun Aug 6, 2023 at 9:46 PM AEST, Nicholas Piggin wrote:
> >> On Fri Aug 4, 2023 at 6:50 PM AEST, Pavel Dovgalyuk wrote:
> >>> BTW, there is a function qemu_register_reset_nosnapshotload that can be
> >>> used in similar cases.
> >>> Can you just use it without changing the code of the reset handler?
> >>
> >> I didn't know that, thanks for pointing it out. I'll take a closer look
> >> at it before reposting.
> > 
> > Seems a bit tricky because the device tree has to be rebuilt at reset
> > time (including snapshot load), but it uses the random number. So
>
> It seems strange to me, that loading the existing configuration has to 
> randomize the device tree.

Building the device tree requires a random number for one of the
properties.

Other architectures that don't have this "cas" firmware call that
changes the device tree and so requires it is rebuilt at machine
reset time just build the device tree once at machine creation time
I believe.

So spapr is already weird in that way. We could go the way that
other archs have and just save that random number once at
creation and then reuse it for each reset. I thought that was not
so good because for a normal reset I think it is better to get a
new random number each time, no?

So I think it's natural enough to take a new random number for a
regular reset, but keep the existing one for a snapshot reset. I
could be misunderstanding something though.

Thanks,
Nick

>
> > having a second nosnapshotload reset function might not be called in
> > the correct order, I think?  For now I will keep it as is.
>
> Ok, let's wait for other reviewers.
>
>
> Pavel Dovgalyuk