Hi Paolo, Thanks for your review.
On Thu, Jul 21, 2022 at 11:19:40AM +0200, Paolo Bonzini wrote: > The issue with live migration is that the setup data changes from before > to after the patches. This means that a live migration exactly _in the > middle_ of reading the Linux boot data could fail badly. For example, > you could migrate in the middle of reading the DTB, and it would be > shifted by the ~50 bytes of the setup_data and seed. The size would > also not match so, even though probably things would mostly work if you > place the seed last, that's not really optimal either. This doesn't really make sense to me, as I don't think the machine can even be migrated during x86_load_linux(), and a migration will skip this whole step anyway since this is mutable memory that a live kernel does mutate. However, what I'll do is reverse the order of these, so that the DTB is added first, and I'll only set up the links in the right order so that there's no potential race. I'll send a v+1 doing this shortly. I would really very much prefer *not* adding a useless knob for this feature, especially not one that's off by default. The idea is to finally fix randomness for VMs globally in a non-invasive way, and fixing the [implausible] race mentioned above seems like it'll do the trick. > variables of x86_load_linux into a struct for sharing. As I said, it > snowballs a bit, but I should be sending out patches later today. I'll send a patch, as mentioned above. > As an aside, QEMU tends to only include code after Linux supports it, > but it's in your rng tree so the timing is right This one is actually in "tip", which is the x86 tree, so it'll certainly be in 5.20. Jason
