Re: [PATCH] x86/acpi: fix suspend with Xen

2023-01-17 Thread Rafael J. Wysocki
On Tue, Jan 17, 2023 at 4:32 PM Juergen Gross  wrote:
>
> On 17.01.23 15:09, Rafael J. Wysocki wrote:
> > On Mon, Jan 16, 2023 at 7:45 AM Juergen Gross  wrote:
> >>
> >> On 13.01.23 20:40, Rafael J. Wysocki wrote:
> >>> On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross  wrote:
> 
>  Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
>  Xen PV guest") missed one code path accessing real_mode_header, leading
>  to dereferencing NULL when suspending the system under Xen:
> 
>    [  348.284004] PM: suspend entry (deep)
>    [  348.289532] Filesystems sync: 0.005 seconds
>    [  348.291545] Freezing user space processes ... (elapsed 0.000 
>  seconds) done.
>    [  348.292457] OOM killer disabled.
>    [  348.292462] Freezing remaining freezable tasks ... (elapsed 
>  0.104 seconds) done.
>    [  348.396612] printk: Suspending console(s) (use 
>  no_console_suspend to debug)
>    [  348.749228] PM: suspend devices took 0.352 seconds
>    [  348.769713] ACPI: EC: interrupt blocked
>    [  348.816077] BUG: kernel NULL pointer dereference, address: 
>  001c
>    [  348.816080] #PF: supervisor read access in kernel mode
>    [  348.816081] #PF: error_code(0x) - not-present page
>    [  348.816083] PGD 0 P4D 0
>    [  348.816086] Oops:  [#1] PREEMPT SMP NOPTI
>    [  348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 
>  6.1.3-1.fc32.qubes.x86_64 #1
>    [  348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 
>  8.01 07/03/2022
>    [  348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20
> 
>  Fix that by adding an indirection for acpi_get_wakeup_address() which
>  Xen PV dom0 can use to return a dummy non-zero wakeup address (this
>  address won't ever be used, as the real suspend handling is done by the
>  hypervisor).
> >>>
> >>> How exactly does this help?
> >>
> >> I believed the first sentence of the commit message would make this
> >> clear enough.
> >
> > That was clear, but the fix part wasn't really.
> >
> >> I can expand the commit message to go more into detail if you think
> >> this is really needed.
> >
> > IMO calling acpi_set_waking_vector() with a known-invalid wakeup
> > vector address in dom0 is plain confusing.
> >
> > I'm not sure what to do about it yet, but IMV something needs to be done.
>
> Another possibility would be to modify acpi_sleep_prepare(), e.g. like the
> attached patch (compile tested only).

I prefer this to the previous version.  It is much more straightforward IMV.



Re: [PATCH] x86/acpi: fix suspend with Xen

2023-01-17 Thread Juergen Gross

On 17.01.23 15:09, Rafael J. Wysocki wrote:

On Mon, Jan 16, 2023 at 7:45 AM Juergen Gross  wrote:


On 13.01.23 20:40, Rafael J. Wysocki wrote:

On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross  wrote:


Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
Xen PV guest") missed one code path accessing real_mode_header, leading
to dereferencing NULL when suspending the system under Xen:

  [  348.284004] PM: suspend entry (deep)
  [  348.289532] Filesystems sync: 0.005 seconds
  [  348.291545] Freezing user space processes ... (elapsed 0.000 seconds) 
done.
  [  348.292457] OOM killer disabled.
  [  348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 
seconds) done.
  [  348.396612] printk: Suspending console(s) (use no_console_suspend to 
debug)
  [  348.749228] PM: suspend devices took 0.352 seconds
  [  348.769713] ACPI: EC: interrupt blocked
  [  348.816077] BUG: kernel NULL pointer dereference, address: 
001c
  [  348.816080] #PF: supervisor read access in kernel mode
  [  348.816081] #PF: error_code(0x) - not-present page
  [  348.816083] PGD 0 P4D 0
  [  348.816086] Oops:  [#1] PREEMPT SMP NOPTI
  [  348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 
6.1.3-1.fc32.qubes.x86_64 #1
  [  348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 
07/03/2022
  [  348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20

Fix that by adding an indirection for acpi_get_wakeup_address() which
Xen PV dom0 can use to return a dummy non-zero wakeup address (this
address won't ever be used, as the real suspend handling is done by the
hypervisor).


How exactly does this help?


I believed the first sentence of the commit message would make this
clear enough.


That was clear, but the fix part wasn't really.


I can expand the commit message to go more into detail if you think
this is really needed.


IMO calling acpi_set_waking_vector() with a known-invalid wakeup
vector address in dom0 is plain confusing.

I'm not sure what to do about it yet, but IMV something needs to be done.


Another possibility would be to modify acpi_sleep_prepare(), e.g. like the
attached patch (compile tested only).


Juergen
From 5a2de7250c4e8782ed89c7898061815058fa2710 Mon Sep 17 00:00:00 2001
From: Juergen Gross 
Date: Tue, 17 Jan 2023 16:20:04 +0100
Subject: [PATCH] acpi: fix suspend with Xen PV
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
Xen PV guest") missed one code path accessing real_mode_header, leading
to dereferencing NULL when suspending the system under Xen:

[  348.284004] PM: suspend entry (deep)
[  348.289532] Filesystems sync: 0.005 seconds
[  348.291545] Freezing user space processes ... (elapsed 0.000 seconds) done.
[  348.292457] OOM killer disabled.
[  348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 seconds) done.
[  348.396612] printk: Suspending console(s) (use no_console_suspend to debug)
[  348.749228] PM: suspend devices took 0.352 seconds
[  348.769713] ACPI: EC: interrupt blocked
[  348.816077] BUG: kernel NULL pointer dereference, address: 001c
[  348.816080] #PF: supervisor read access in kernel mode
[  348.816081] #PF: error_code(0x) - not-present page
[  348.816083] PGD 0 P4D 0
[  348.816086] Oops:  [#1] PREEMPT SMP NOPTI
[  348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 6.1.3-1.fc32.qubes.x86_64 #1
[  348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 07/03/2022
[  348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20

Fix that by adding an optional acpi callback allowing to skip setting
the wakeup address, as in the Xen PV case this will be handled by the
hypervisor anyway.

Fixes: f1e525009493 ("x86/boot: Skip realmode init code when running as Xen PV guest")
Reported-by: Marek Marczykowski-Górecki 
Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/acpi.h | 8 
 drivers/acpi/sleep.c| 6 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 65064d9f7fa6..8eb74cf386db 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_ACPI_APEI
 # include 
@@ -63,6 +64,13 @@ extern int (*acpi_suspend_lowlevel)(void);
 /* Physical address to resume after wakeup */
 unsigned long acpi_get_wakeup_address(void);
 
+static inline bool acpi_skip_set_wakeup_address(void)
+{
+	return cpu_feature_enabled(X86_FEATURE_XENPV);
+}
+
+#define acpi_skip_set_wakeup_address acpi_skip_set_wakeup_address
+
 /*
  * Check if the CPU can handle C2 and deeper
  */
diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
index 0b557c0d405e..4ca667251272 100644
--- 

Re: [PATCH] x86/acpi: fix suspend with Xen

2023-01-17 Thread Rafael J. Wysocki
On Mon, Jan 16, 2023 at 7:45 AM Juergen Gross  wrote:
>
> On 13.01.23 20:40, Rafael J. Wysocki wrote:
> > On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross  wrote:
> >>
> >> Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
> >> Xen PV guest") missed one code path accessing real_mode_header, leading
> >> to dereferencing NULL when suspending the system under Xen:
> >>
> >>  [  348.284004] PM: suspend entry (deep)
> >>  [  348.289532] Filesystems sync: 0.005 seconds
> >>  [  348.291545] Freezing user space processes ... (elapsed 0.000 
> >> seconds) done.
> >>  [  348.292457] OOM killer disabled.
> >>  [  348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 
> >> seconds) done.
> >>  [  348.396612] printk: Suspending console(s) (use no_console_suspend 
> >> to debug)
> >>  [  348.749228] PM: suspend devices took 0.352 seconds
> >>  [  348.769713] ACPI: EC: interrupt blocked
> >>  [  348.816077] BUG: kernel NULL pointer dereference, address: 
> >> 001c
> >>  [  348.816080] #PF: supervisor read access in kernel mode
> >>  [  348.816081] #PF: error_code(0x) - not-present page
> >>  [  348.816083] PGD 0 P4D 0
> >>  [  348.816086] Oops:  [#1] PREEMPT SMP NOPTI
> >>  [  348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 
> >> 6.1.3-1.fc32.qubes.x86_64 #1
> >>  [  348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 
> >> 07/03/2022
> >>  [  348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20
> >>
> >> Fix that by adding an indirection for acpi_get_wakeup_address() which
> >> Xen PV dom0 can use to return a dummy non-zero wakeup address (this
> >> address won't ever be used, as the real suspend handling is done by the
> >> hypervisor).
> >
> > How exactly does this help?
>
> I believed the first sentence of the commit message would make this
> clear enough.

That was clear, but the fix part wasn't really.

> I can expand the commit message to go more into detail if you think
> this is really needed.

IMO calling acpi_set_waking_vector() with a known-invalid wakeup
vector address in dom0 is plain confusing.

I'm not sure what to do about it yet, but IMV something needs to be done.



Re: [PATCH] x86/acpi: fix suspend with Xen

2023-01-15 Thread Juergen Gross

On 13.01.23 20:40, Rafael J. Wysocki wrote:

On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross  wrote:


Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
Xen PV guest") missed one code path accessing real_mode_header, leading
to dereferencing NULL when suspending the system under Xen:

 [  348.284004] PM: suspend entry (deep)
 [  348.289532] Filesystems sync: 0.005 seconds
 [  348.291545] Freezing user space processes ... (elapsed 0.000 seconds) 
done.
 [  348.292457] OOM killer disabled.
 [  348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 
seconds) done.
 [  348.396612] printk: Suspending console(s) (use no_console_suspend to 
debug)
 [  348.749228] PM: suspend devices took 0.352 seconds
 [  348.769713] ACPI: EC: interrupt blocked
 [  348.816077] BUG: kernel NULL pointer dereference, address: 
001c
 [  348.816080] #PF: supervisor read access in kernel mode
 [  348.816081] #PF: error_code(0x) - not-present page
 [  348.816083] PGD 0 P4D 0
 [  348.816086] Oops:  [#1] PREEMPT SMP NOPTI
 [  348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 
6.1.3-1.fc32.qubes.x86_64 #1
 [  348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 
07/03/2022
 [  348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20

Fix that by adding an indirection for acpi_get_wakeup_address() which
Xen PV dom0 can use to return a dummy non-zero wakeup address (this
address won't ever be used, as the real suspend handling is done by the
hypervisor).


How exactly does this help?


I believed the first sentence of the commit message would make this
clear enough.

I can expand the commit message to go more into detail if you think
this is really needed.


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH] x86/acpi: fix suspend with Xen

2023-01-13 Thread Marek Marczykowski-Górecki
On Fri, Jan 13, 2023 at 08:40:15PM +0100, Rafael J. Wysocki wrote:
> On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross  wrote:
> >
> > Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
> > Xen PV guest") missed one code path accessing real_mode_header, leading
> > to dereferencing NULL when suspending the system under Xen:
> >
> > [  348.284004] PM: suspend entry (deep)
> > [  348.289532] Filesystems sync: 0.005 seconds
> > [  348.291545] Freezing user space processes ... (elapsed 0.000 
> > seconds) done.
> > [  348.292457] OOM killer disabled.
> > [  348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 
> > seconds) done.
> > [  348.396612] printk: Suspending console(s) (use no_console_suspend to 
> > debug)
> > [  348.749228] PM: suspend devices took 0.352 seconds
> > [  348.769713] ACPI: EC: interrupt blocked
> > [  348.816077] BUG: kernel NULL pointer dereference, address: 
> > 001c
> > [  348.816080] #PF: supervisor read access in kernel mode
> > [  348.816081] #PF: error_code(0x) - not-present page
> > [  348.816083] PGD 0 P4D 0
> > [  348.816086] Oops:  [#1] PREEMPT SMP NOPTI
> > [  348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 
> > 6.1.3-1.fc32.qubes.x86_64 #1
> > [  348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 
> > 07/03/2022
> > [  348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20
> >
> > Fix that by adding an indirection for acpi_get_wakeup_address() which
> > Xen PV dom0 can use to return a dummy non-zero wakeup address (this
> > address won't ever be used, as the real suspend handling is done by the
> > hypervisor).
> 
> How exactly does this help?

By not accessing calling acpi_get_wakeup_address() (with the patch
renamed to x86_acpi_get_wakeup_address()) during PV dom0 suspend, which
otherwise would access not initialized real_mode_header.

I confirm this patch fixes the issue.

> > Fixes: f1e525009493 ("x86/boot: Skip realmode init code when running as Xen 
> > PV guest")
> > Reported-by: Marek Marczykowski-Górecki 
> > Signed-off-by: Juergen Gross 
> > ---
> >  arch/x86/include/asm/acpi.h  | 2 +-
> >  arch/x86/kernel/acpi/sleep.c | 3 ++-
> >  include/xen/acpi.h   | 9 +
> >  3 files changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
> > index 65064d9f7fa6..137259ff8f03 100644
> > --- a/arch/x86/include/asm/acpi.h
> > +++ b/arch/x86/include/asm/acpi.h
> > @@ -61,7 +61,7 @@ static inline void acpi_disable_pci(void)
> >  extern int (*acpi_suspend_lowlevel)(void);
> >
> >  /* Physical address to resume after wakeup */
> > -unsigned long acpi_get_wakeup_address(void);
> > +extern unsigned long (*acpi_get_wakeup_address)(void);
> >
> >  /*
> >   * Check if the CPU can handle C2 and deeper
> > diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c
> > index 3b7f4cdbf2e0..1a3cd5e24cd0 100644
> > --- a/arch/x86/kernel/acpi/sleep.c
> > +++ b/arch/x86/kernel/acpi/sleep.c
> > @@ -33,10 +33,11 @@ static char temp_stack[4096];
> >   * Returns the physical address where the kernel should be resumed after 
> > the
> >   * system awakes from S3, e.g. for programming into the firmware waking 
> > vector.
> >   */
> > -unsigned long acpi_get_wakeup_address(void)
> > +static unsigned long x86_acpi_get_wakeup_address(void)
> >  {
> > return ((unsigned long)(real_mode_header->wakeup_start));
> >  }
> > +unsigned long (*acpi_get_wakeup_address)(void) = 
> > x86_acpi_get_wakeup_address;
> >
> >  /**
> >   * x86_acpi_enter_sleep_state - enter sleep state
> > diff --git a/include/xen/acpi.h b/include/xen/acpi.h
> > index b1e11863144d..7e1e5dbfb77c 100644
> > --- a/include/xen/acpi.h
> > +++ b/include/xen/acpi.h
> > @@ -56,6 +56,12 @@ static inline int xen_acpi_suspend_lowlevel(void)
> > return 0;
> >  }
> >
> > +static inline unsigned long xen_acpi_get_wakeup_address(void)
> > +{
> > +   /* Just return a dummy non-zero value, it will never be used. */
> > +   return 1;
> > +}
> > +
> >  static inline void xen_acpi_sleep_register(void)
> >  {
> > if (xen_initial_domain()) {
> > @@ -65,6 +71,9 @@ static inline void xen_acpi_sleep_register(void)
> > _acpi_notify_hypervisor_extended_sleep);
> >
> > acpi_suspend_lowlevel = xen_acpi_suspend_lowlevel;
> > +#ifdef CONFIG_ACPI_SLEEP
> > +   acpi_get_wakeup_address = xen_acpi_get_wakeup_address;
> > +#endif
> > }
> >  }
> >  #else
> > --
> > 2.35.3
> >

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab


signature.asc
Description: PGP signature


Re: [PATCH] x86/acpi: fix suspend with Xen

2023-01-13 Thread Rafael J. Wysocki
On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross  wrote:
>
> Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
> Xen PV guest") missed one code path accessing real_mode_header, leading
> to dereferencing NULL when suspending the system under Xen:
>
> [  348.284004] PM: suspend entry (deep)
> [  348.289532] Filesystems sync: 0.005 seconds
> [  348.291545] Freezing user space processes ... (elapsed 0.000 seconds) 
> done.
> [  348.292457] OOM killer disabled.
> [  348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 
> seconds) done.
> [  348.396612] printk: Suspending console(s) (use no_console_suspend to 
> debug)
> [  348.749228] PM: suspend devices took 0.352 seconds
> [  348.769713] ACPI: EC: interrupt blocked
> [  348.816077] BUG: kernel NULL pointer dereference, address: 
> 001c
> [  348.816080] #PF: supervisor read access in kernel mode
> [  348.816081] #PF: error_code(0x) - not-present page
> [  348.816083] PGD 0 P4D 0
> [  348.816086] Oops:  [#1] PREEMPT SMP NOPTI
> [  348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 
> 6.1.3-1.fc32.qubes.x86_64 #1
> [  348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 
> 07/03/2022
> [  348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20
>
> Fix that by adding an indirection for acpi_get_wakeup_address() which
> Xen PV dom0 can use to return a dummy non-zero wakeup address (this
> address won't ever be used, as the real suspend handling is done by the
> hypervisor).

How exactly does this help?

> Fixes: f1e525009493 ("x86/boot: Skip realmode init code when running as Xen 
> PV guest")
> Reported-by: Marek Marczykowski-Górecki 
> Signed-off-by: Juergen Gross 
> ---
>  arch/x86/include/asm/acpi.h  | 2 +-
>  arch/x86/kernel/acpi/sleep.c | 3 ++-
>  include/xen/acpi.h   | 9 +
>  3 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
> index 65064d9f7fa6..137259ff8f03 100644
> --- a/arch/x86/include/asm/acpi.h
> +++ b/arch/x86/include/asm/acpi.h
> @@ -61,7 +61,7 @@ static inline void acpi_disable_pci(void)
>  extern int (*acpi_suspend_lowlevel)(void);
>
>  /* Physical address to resume after wakeup */
> -unsigned long acpi_get_wakeup_address(void);
> +extern unsigned long (*acpi_get_wakeup_address)(void);
>
>  /*
>   * Check if the CPU can handle C2 and deeper
> diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c
> index 3b7f4cdbf2e0..1a3cd5e24cd0 100644
> --- a/arch/x86/kernel/acpi/sleep.c
> +++ b/arch/x86/kernel/acpi/sleep.c
> @@ -33,10 +33,11 @@ static char temp_stack[4096];
>   * Returns the physical address where the kernel should be resumed after the
>   * system awakes from S3, e.g. for programming into the firmware waking 
> vector.
>   */
> -unsigned long acpi_get_wakeup_address(void)
> +static unsigned long x86_acpi_get_wakeup_address(void)
>  {
> return ((unsigned long)(real_mode_header->wakeup_start));
>  }
> +unsigned long (*acpi_get_wakeup_address)(void) = x86_acpi_get_wakeup_address;
>
>  /**
>   * x86_acpi_enter_sleep_state - enter sleep state
> diff --git a/include/xen/acpi.h b/include/xen/acpi.h
> index b1e11863144d..7e1e5dbfb77c 100644
> --- a/include/xen/acpi.h
> +++ b/include/xen/acpi.h
> @@ -56,6 +56,12 @@ static inline int xen_acpi_suspend_lowlevel(void)
> return 0;
>  }
>
> +static inline unsigned long xen_acpi_get_wakeup_address(void)
> +{
> +   /* Just return a dummy non-zero value, it will never be used. */
> +   return 1;
> +}
> +
>  static inline void xen_acpi_sleep_register(void)
>  {
> if (xen_initial_domain()) {
> @@ -65,6 +71,9 @@ static inline void xen_acpi_sleep_register(void)
> _acpi_notify_hypervisor_extended_sleep);
>
> acpi_suspend_lowlevel = xen_acpi_suspend_lowlevel;
> +#ifdef CONFIG_ACPI_SLEEP
> +   acpi_get_wakeup_address = xen_acpi_get_wakeup_address;
> +#endif
> }
>  }
>  #else
> --
> 2.35.3
>



[PATCH] x86/acpi: fix suspend with Xen

2023-01-13 Thread Juergen Gross
Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
Xen PV guest") missed one code path accessing real_mode_header, leading
to dereferencing NULL when suspending the system under Xen:

[  348.284004] PM: suspend entry (deep)
[  348.289532] Filesystems sync: 0.005 seconds
[  348.291545] Freezing user space processes ... (elapsed 0.000 seconds) 
done.
[  348.292457] OOM killer disabled.
[  348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 
seconds) done.
[  348.396612] printk: Suspending console(s) (use no_console_suspend to 
debug)
[  348.749228] PM: suspend devices took 0.352 seconds
[  348.769713] ACPI: EC: interrupt blocked
[  348.816077] BUG: kernel NULL pointer dereference, address: 
001c
[  348.816080] #PF: supervisor read access in kernel mode
[  348.816081] #PF: error_code(0x) - not-present page
[  348.816083] PGD 0 P4D 0
[  348.816086] Oops:  [#1] PREEMPT SMP NOPTI
[  348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 
6.1.3-1.fc32.qubes.x86_64 #1
[  348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 
07/03/2022
[  348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20

Fix that by adding an indirection for acpi_get_wakeup_address() which
Xen PV dom0 can use to return a dummy non-zero wakeup address (this
address won't ever be used, as the real suspend handling is done by the
hypervisor).

Fixes: f1e525009493 ("x86/boot: Skip realmode init code when running as Xen PV 
guest")
Reported-by: Marek Marczykowski-Górecki 
Signed-off-by: Juergen Gross 
---
 arch/x86/include/asm/acpi.h  | 2 +-
 arch/x86/kernel/acpi/sleep.c | 3 ++-
 include/xen/acpi.h   | 9 +
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/acpi.h b/arch/x86/include/asm/acpi.h
index 65064d9f7fa6..137259ff8f03 100644
--- a/arch/x86/include/asm/acpi.h
+++ b/arch/x86/include/asm/acpi.h
@@ -61,7 +61,7 @@ static inline void acpi_disable_pci(void)
 extern int (*acpi_suspend_lowlevel)(void);
 
 /* Physical address to resume after wakeup */
-unsigned long acpi_get_wakeup_address(void);
+extern unsigned long (*acpi_get_wakeup_address)(void);
 
 /*
  * Check if the CPU can handle C2 and deeper
diff --git a/arch/x86/kernel/acpi/sleep.c b/arch/x86/kernel/acpi/sleep.c
index 3b7f4cdbf2e0..1a3cd5e24cd0 100644
--- a/arch/x86/kernel/acpi/sleep.c
+++ b/arch/x86/kernel/acpi/sleep.c
@@ -33,10 +33,11 @@ static char temp_stack[4096];
  * Returns the physical address where the kernel should be resumed after the
  * system awakes from S3, e.g. for programming into the firmware waking vector.
  */
-unsigned long acpi_get_wakeup_address(void)
+static unsigned long x86_acpi_get_wakeup_address(void)
 {
return ((unsigned long)(real_mode_header->wakeup_start));
 }
+unsigned long (*acpi_get_wakeup_address)(void) = x86_acpi_get_wakeup_address;
 
 /**
  * x86_acpi_enter_sleep_state - enter sleep state
diff --git a/include/xen/acpi.h b/include/xen/acpi.h
index b1e11863144d..7e1e5dbfb77c 100644
--- a/include/xen/acpi.h
+++ b/include/xen/acpi.h
@@ -56,6 +56,12 @@ static inline int xen_acpi_suspend_lowlevel(void)
return 0;
 }
 
+static inline unsigned long xen_acpi_get_wakeup_address(void)
+{
+   /* Just return a dummy non-zero value, it will never be used. */
+   return 1;
+}
+
 static inline void xen_acpi_sleep_register(void)
 {
if (xen_initial_domain()) {
@@ -65,6 +71,9 @@ static inline void xen_acpi_sleep_register(void)
_acpi_notify_hypervisor_extended_sleep);
 
acpi_suspend_lowlevel = xen_acpi_suspend_lowlevel;
+#ifdef CONFIG_ACPI_SLEEP
+   acpi_get_wakeup_address = xen_acpi_get_wakeup_address;
+#endif
}
 }
 #else
-- 
2.35.3