Thread (44 messages) 44 messages, 7 authors, 2020-08-05

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

From: Anchal Agarwal <hidden>
Date: 2020-08-04 23:42:33
Also in: linux-mm, lkml, netdev, xen-devel

On Fri, Jul 31, 2020 at 10:13:48AM -0400, Boris Ostrovsky 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 7/30/20 7:06 PM, Anchal Agarwal wrote:
quoted
On Mon, Jul 27, 2020 at 06:08:29PM -0400, Boris Ostrovsky wrote:
quoted
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 7/24/20 7:01 PM, Stefano Stabellini wrote:
quoted
Yes, it does, thank you. I'd rather not introduce unknown regressions so
I would recommend to add an arch-specific check on registering
freeze/thaw/restore handlers. Maybe something like the following:

#ifdef CONFIG_X86
    .freeze = blkfront_freeze,
    .thaw = blkfront_restore,
    .restore = blkfront_restore
#endif


maybe Boris has a better suggestion on how to do it
An alternative might be to still install pm notifier in
drivers/xen/manage.c (I think as result of latest discussions we decided
we won't need it) and return -ENOTSUPP for ARM for
PM_HIBERNATION_PREPARE and friends. Would that work?
I think the question here is for registering driver specific freeze/thaw/restore
callbacks for x86 only. I have dropped the pm_notifier in the v3 still pending
testing. So I think just registering driver specific callbacks for x86 only is a
good option. What do you think?

I suggested using the notifier under assumption that if it returns an
error then that will prevent callbacks to be called because hibernation
will be effectively disabled. But I haven't looked at PM code so I don't
know whether this is actually the case.
I think this could be done. PM_HIBERNATION_PREPARE could return -ENOTSUPP
for arm and pvh dom0 when the notifier call chain is invoked for this case
in hibernate(). This will then be an empty notifier just for checking two
usecases.
Also, for pvh dom0, the earlier code didn't register any notifier,
with this approach you are suggesting setup the notifier for hvm/pvh dom0 and
arm but fail during notifier call chain during PM_HIBERNATION_PREPARE ?

I think still getting rid of suspend mode that was earlier a part of this
notifier is a good idea as it seems redundant as you pointed out earlier. 
The advantage of doing it in the notifier is that instead of adding
ifdefs to each driver you will be able to prevent callbacks from a
single place. Plus you can use this do disable hibernation for PVH dom0
as well.



-boris
Anchal
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help