From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org,
Alistair Francis <alistair.francis@wdc.com>,
David Gibson <david@gibson.dropbear.id.au>,
Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru>,
Paolo Bonzini <pbonzini@redhat.com>,
Juan Quintela <quintela@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH 1/6] device-tree: add re-randomization helper function
Date: Mon, 10 Oct 2022 09:20:54 -0600 [thread overview]
Message-ID: <Y0Q4Vugq+d0vaF97@zx2c4.com> (raw)
In-Reply-To: <CAFEAcA-fOdNeDz9_Hbm7R3_3o2T4Zw8wPrgOtVLK9tUNMciZow@mail.gmail.com>
On Mon, Oct 10, 2022 at 11:54:50AM +0100, Peter Maydell wrote:
> The error is essentially the record-and-replay subsystem saying "the
> replay just asked for a random number at point when the recording
> did not ask for one, and so there's no 'this is what the number was'
> info in the record".
>
> I have had a quick look, and I think the reason for this is that
> load_snapshot() ("reset the VM state to the snapshot state stored in the
> disk image or migration stream") does a system reset. The replay
> process involves a lot of "load state from a snapshot and play
> forwards from there" operations. It doesn't expect that load_snapshot()
> would result in something reading random data, but now that we are
> calling qemu_guest_getrandom() in a reset hook, that happens.
Hmm... so this seems like a bug in the replay code then? Shouldn't that
reset handler get hit during both passes, so the entry should be in
each?
Jason
next prev parent reply other threads:[~2022-10-10 15:40 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-29 23:23 [PATCH 1/6] device-tree: add re-randomization helper function Jason A. Donenfeld
2022-09-29 23:23 ` [PATCH 2/6] arm: re-randomize rng-seed on reboot Jason A. Donenfeld
2022-09-30 9:11 ` Bin Meng
2022-09-29 23:23 ` [PATCH 3/6] riscv: " Jason A. Donenfeld
2022-09-30 9:11 ` Bin Meng
2022-10-10 2:56 ` Alistair Francis
2022-09-29 23:23 ` [PATCH 4/6] openrisc: " Jason A. Donenfeld
2022-09-30 9:11 ` Bin Meng
2022-09-29 23:23 ` [PATCH 5/6] rx: " Jason A. Donenfeld
2022-09-30 9:11 ` Bin Meng
2022-10-01 13:13 ` Yoshinori Sato
2022-09-29 23:23 ` [PATCH 6/6] mips: " Jason A. Donenfeld
2022-09-30 9:11 ` Bin Meng
2022-09-30 8:44 ` [PATCH 1/6] device-tree: add re-randomization helper function Bin Meng
2022-10-06 13:16 ` Peter Maydell
2022-10-06 13:17 ` Jason A. Donenfeld
2022-10-10 10:54 ` Peter Maydell
2022-10-10 10:58 ` Peter Maydell
2022-10-10 15:20 ` Jason A. Donenfeld [this message]
2022-10-10 15:32 ` Peter Maydell
2022-10-10 15:50 ` Jason A. Donenfeld
2022-10-11 6:46 ` Pavel Dovgalyuk
2022-10-11 20:06 ` Jason A. Donenfeld
2022-10-11 20:40 ` Jason A. Donenfeld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y0Q4Vugq+d0vaF97@zx2c4.com \
--to=jason@zx2c4.com \
--cc=alistair.francis@wdc.com \
--cc=david@gibson.dropbear.id.au \
--cc=dgilbert@redhat.com \
--cc=pavel.dovgalyuk@ispras.ru \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.