On 7/21/22 13:00, Michael S. Tsirkin wrote:
Well why not.
Reviewed-by: Michael S. Tsirkin<m...@redhat.com>
who's merging this? Paolo me or you?
I don't think this should be merged as is.
The linuxboot ROM takes the data from fw_cfg, and (with the exception of
ACPI tables) that data is not migrated. Because reading it into the
guest is not atomic, both sides must match. This version of the patches
at least doesn't move the preexisting DTB entry of the setup_data, but
it still has a mismatching size and that can be a problem when migrating
backwards.
So for example there is a race window where the guest has read the list
head that points to the random number seed entry, but the entry isn't
there on the destination.
Note that I _do_ agree that this is theoretical and basically impossible
to hit. On the other hand, it is there and it's just not the way that
we've handled guest ABI compatibility: migration issues are already not
fun to debug without having to keep track of which differences are
intentional and "harmless" differences and which are bugs. So for this
particular case the structure of fw_cfg data MUST match on the source
and destination given a machine type and options.
Thinking more about it, it's trivial to hit it if you use TCG
record-replay, because if the record and replay side will get different
sizes fw_cfg and then everything goes south. This shows why this
mindset is the correct one even for issues that are theoretical in the
case migration: if we hadn't, record-replay would have been much harder
to implement.
Of course I'm not going to introduce a whole machinery to migrate the
seed: if you want determinism (as in the record-replay case) there is
the -seed option, if you don't then it's not a huge deal to have a seed
that could theoretically be generated half on the source half on the
destination.
And in fact, after some refactoring, the changes aren't hard to do. My
patch is 35(+) 0(-).
Paolo
