>>>>>>> Also, wrt KASLR stuff, that issue is still seen sometimes but I haven't had >>>>>>> bandwidth to dive deep into the issue and fix it. >>>> So what's the plan there? You first mentioned this issue early this year and judged by your response it is not clear whether you will ever spend time looking at it. >>>> >>> I do want to fix it and did do some debugging earlier this year just haven't >>> gotten back to it. Also, wanted to understand if the issue is a blocker to this >>> series? >> >> Integrating code with known bugs is less than ideal. >> > So for this series to be accepted, KASLR needs to be fixed along with other > comments of course? Yes, please. >>> I had some theories when debugging around this like if the random base address picked by kaslr for the >>> resuming kernel mismatches the suspended kernel and just jogging my memory, I didn't find that as the case. >>> Another hunch was if physical address of registered vcpu info at boot is different from what suspended kernel >>> has and that can cause CPU's to get stuck when coming online. >> >> I'd think if this were the case you'd have 100% failure rate. And we are also re-registering vcpu info on xen restore and I am not aware of any failures due to KASLR. >> > What I meant there wrt VCPU info was that VCPU info is not unregistered during hibernation, > so Xen still remembers the old physical addresses for the VCPU information, created by the > booting kernel. But since the hibernation kernel may have different physical > addresses for VCPU info and if mismatch happens, it may cause issues with resume. > During hibernation, the VCPU info register hypercall is not invoked again. I still don't think that's the cause but it's certainly worth having a look. -boris
