Hey again, On Thu, Jul 21, 2022 at 11:47:29AM +0200, Jason A. Donenfeld wrote: > 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.
As I implement the "race-free" version, I notice that this is even more of a non-issue, seeing as even without this patch, the DTB is loaded after the length is written. What you're talking about is just not real. I'll still send a v+1 changing the order, because that seems better anyway, but the race thing seems pretty imaginary... Jason
