Serge E. Hallyn wrote: > Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx): >> >> Serge E. Hallyn wrote: >>> Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx): >>>> Serge E. Hallyn wrote: >>>>> Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx): >>>>>> Serge E. Hallyn wrote: >>>>>>> Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx): >>>>>>>> Cool ! >>>>>>>> >>>>>>>> So what do we have working now for 64 bit kernel (for 32 bit kernel >>>>>>>> we know it works...): >>>>>>>> >>>>>>>> 'restart' checkpointed >>>>>>>> program program >>>>>>>> ---------------------------------------- >>>>>>>> 64bit 64bit -> works >>>>>>>> 32bit 32bit -> works >>>>>>>> >>>>>>>> 64bit 32bit -> ????? >>> s/?????/Rejected/ >>> >>> CKPT_ARCH_ID is of course different for X86_32 than X86_64, so >>> we refuse restart in restore_read_header(). >>> >>> -serge >>> >> lol ... that's actually funny ! >> >> Anyway, in light of the IRC discussions, here are the cases again: >> >> >> original original restart target >> program kernel program kernel >> -------- --------- -------- -------- >> 64 bit 64 bit 64 bit 64 bit [0] works >> >> 32 bit 32 bit 32 bit 32 bit [0] works >> 32 bit 64 bit 32 bit 64 bit [0] works >> >> 32 bit 32 bit 32 bit 64 bit [1] >> 32 bit 64 bit 32 bit 32 bit [1] >> >> 32 bit any 64 bit 64 bit [2] >> 64 bit 64 bit 32 bit 64 bit [2] >> >> [0] The first 3 cases are "homogeneous", with conditions equal at >> checkpoint and restart. AFAIK, they work. >> >> [1] The next two cases consider 32 bit program, and vary only the >> environment - the kernel may change from 32 to 64 or back. We want >> them to work. >> >> IIUC, your comment above means that they don't work because the >> CKPT_ARCH_ID is a mismatch. The fix should be trivial - either >> make 'restart' modify it, or make the kernel tolerate it. > > Well, you'd think so, but we also check for uts->machine, and want > to eventually check for kernel config, both of which are obviously > different. Then we'll have to take that in account when we get to also check those other fields. > > After I comment out the obvious offending checks, it still fails to > restart from x8632->x86-64. I can spend some time next week figuring > out what we're not quite doing right as there shouldn't be a > problem really. But do we definately want to go out of our way to try > and mask out the differences in this case, while trying to detect > cpu differences between two x86-32's for instance? I agree, there shouldn't be a problem really, and I expect this to be a very useful feature for migration/fault-tolerance. Checking for differences between CPU's is a separate issue, and is orthogonal to migration (of 32bit programs) between 32 and 64 bit kernels. I tend to answer "yes" - we should eventually refuse restart if we detect that the "configuration" at restart time differs from that at checkpoint time "sufficiently". Now "configuration" is very basic - the architecture. I would like that to also include cpu features, kernel features, fpu capabilities... Also "sufficiently" is vaguely defined, because I don't know enough to describe it more precisely. Ideally there will be some clever user-space logic that will detect and make a decision. And, yes, it will take a lot of details... Oren. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
