linux-kernel - Re: [PATCH 1/2] xenbus: Use .freeze/.thaw to handle xenbus devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ce270a90-ffc4-45f8-9af6-be9aa1c49162@amd.com>
Date: Mon, 1 Dec 2025 12:15:17 -0500
From: Jason Andryuk <jason.andryuk@....com>
To: Yann Sionneau <yann.sionneau@...es.tech>, Juergen Gross <jgross@...e.com>,
	Stefano Stabellini <sstabellini@...nel.org>, Oleksandr Tyshchenko
	<oleksandr_tyshchenko@...m.com>
CC: <xen-devel@...ts.xenproject.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] xenbus: Use .freeze/.thaw to handle xenbus devices

On 2025-11-26 10:00, Yann Sionneau wrote:
> Hi Jason,
> 
> On 11/19/25 23:46, Jason Andryuk wrote:
>> The goal is to fix s2idle and S3 for Xen PV devices.  A domain resuming
>> from s3 or s2idle disconnects its PV devices during resume.  The
>> backends are not expecting this and do not reconnect.
>>
>> b3e96c0c7562 ("xen: use freeze/restore/thaw PM events for suspend/
>> resume/chkpt") changed xen_suspend()/do_suspend() from
>> PMSG_SUSPEND/PMSG_RESUME to PMSG_FREEZE/PMSG_THAW/PMSG_RESTORE, but the
>> suspend/resume callbacks remained.
>>
>> .freeze/restore are used with hiberation where Linux restarts in a new
>> place in the future.  .suspend/resume are useful for runtime power
>> management for the duration of a boot.
>>
>> The current behavior of the callbacks works for an xl save/restore or
>> live migration where the domain is restored/migrated to a new location
>> and connecting to a not-already-connected backend.
>>
>> Change xenbus_pm_ops to use .freeze/thaw/restore and drop the
>> .suspend/resume hook.  This matches the use in drivers/xen/manage.c for
>> save/restore and live migration.  With .suspend/resume empty, PV devices
>> are left connected during s2idle and s3, so PV devices are not changed
>> and work after resume.
>>
>> Signed-off-by: Jason Andryuk <jason.andryuk@....com>
>> ---
>>    drivers/xen/xenbus/xenbus_probe_frontend.c | 4 +---
>>    1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/xen/xenbus/xenbus_probe_frontend.c b/drivers/xen/xenbus/xenbus_probe_frontend.c
>> index 6d1819269cbe..199917b6f77c 100644
>> --- a/drivers/xen/xenbus/xenbus_probe_frontend.c
>> +++ b/drivers/xen/xenbus/xenbus_probe_frontend.c
>> @@ -148,11 +148,9 @@ static void xenbus_frontend_dev_shutdown(struct device *_dev)
>>    }
>>    
>>    static const struct dev_pm_ops xenbus_pm_ops = {
>> -	.suspend	= xenbus_dev_suspend,
>> -	.resume		= xenbus_frontend_dev_resume,
>>    	.freeze		= xenbus_dev_suspend,
>>    	.thaw		= xenbus_dev_cancel,
>> -	.restore	= xenbus_dev_resume,
>> +	.restore	= xenbus_frontend_dev_resume,
>>    };
>>    
>>    static struct xen_bus_type xenbus_frontend = {
> 
> I've tried putting Debian 13 to sleep with your patch (echo freeze >
> /sys/power/state) and could not wake up the guest.
> Isn't it also mandatory to apply this patch
> https://github.com/QubesOS/qubes-linux-kernel/blob/main/xen-events-Add-wakeup-support-to-xen-pirq.patch
> ?
> 
> With both patches applied, I get the wake up to work.

I did not need the additional patch.  I thought it was necessary for 
dom0 s0ix wakeup which uses xen-pirq for hardware interrupts.  I did not 
think it was necessary for a domU.  I'm only looking at the domU case 
here, and this code is for frontend PV devices.

In my setup, I use `xl trigger $dom sleep` to enter (and exit) s2idle 
for a PVH domain, which has the ACPI buttons exposed with X86_EMU_PM. 
This is a non-standard configuration.

I've additionally tested with `echo mem > /sys/power/state` to enter 
s2idle.  Again waking with `xl trigger $dom sleep`.

xl console remains connected, but typing there does not wake.

What kind of guest are you testing with?  How do you wake it?  If it's 
HVM in S3, another way to attempt wake up may be `xl 
qemu-monitor-command $dom system_wakeup`.

Regards,
Jason