Re: [PATCH v3 01/11] xen/manage: keep track of the on-going suspend mode

[Anchal Agarwal <anchalag@amazon.com>]

On Fri, Sep 25, 2020 at 04:02:58PM -0400, boris.ostrovsky@oracle.com wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> On 9/25/20 3:04 PM, Anchal Agarwal wrote:
> > On Tue, Sep 22, 2020 at 11:17:36PM +0000, Anchal Agarwal wrote:
> >> On Tue, Sep 22, 2020 at 12:18:05PM -0400, boris.ostrovsky@oracle.com wrote:
> >>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> >>>
> >>>
> >>>
> >>> On 9/21/20 5:54 PM, Anchal Agarwal wrote:
> >>>> Thanks for the above suggestion. You are right I didn't find a way to declare
> >>>> a global state either. I just broke the above check in 2 so that once we have
> >>>> support for ARM we should be able to remove aarch64 condition easily. Let me
> >>>> know if I am missing nay corner cases with this one.
> >>>>
> >>>> static int xen_pm_notifier(struct notifier_block *notifier,
> >>>>       unsigned long pm_event, void *unused)
> >>>> {
> >>>>     int ret = NOTIFY_OK;
> >>>>     if (!xen_hvm_domain() || xen_initial_domain())
> >>>>       ret = NOTIFY_BAD;
> >>>>     if(IS_ENABLED(CONFIG_ARM64) && (pm_event == PM_SUSPEND_PREPARE || pm_event == HIBERNATION_PREPARE))
> >>>>       ret = NOTIFY_BAD;
> >>>>
> >>>>     return ret;
> >>>> }
> >>>
> >>>
> >>> This will allow PM suspend to proceed on x86.
> >> Right!! Missed it.
> >> 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?
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. The issue was only
reproducible 3% of the time out of 3000 runs hence its hard to just reproduce this.

Moreover, I also wanted to get an insight on if hibernation works correctly with KASLR
generally and its only Xen causing the issue?
> 
> >>  I seem to have lost your email
> >> in my inbox hence covering the question here.
> >>>
> > Can I add your Reviewed-by or Signed-off-by to it?
> 
> 
> Are you asking me to add my R-b to the broken code above?
> 
Of course not!! After its fixed.
Well can forget it for now then!
> 
> -boris
> 
Thanks,
Anchal