xen/arch/x86/x86_64/entry.S | 2 ++ xen/common/Kconfig | 4 ++++ xen/common/Makefile | 2 +- xen/include/xen/sched.h | 2 ++ xen/include/xen/wait.h | 11 +++++++++-- 5 files changed, 18 insertions(+), 3 deletions(-)
wait.c is only used by vm_event.c. Make CONFIG_VM_EVENT select
CONFIG_WAIT, and use CONFIG_WAIT to control building it.
Provide stubs of functions called from common code. entry.S needs an
ifdef to hide the symbol from the assembly.
Also conditionalize .waitqueue_vcpu in struct vcpu to save space.
Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
---
xen/arch/x86/x86_64/entry.S | 2 ++
xen/common/Kconfig | 4 ++++
xen/common/Makefile | 2 +-
xen/include/xen/sched.h | 2 ++
xen/include/xen/wait.h | 11 +++++++++--
5 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index ca446c6ff0..adb570c07e 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -664,7 +664,9 @@ FUNC(continue_pv_domain)
ALTERNATIVE "", "mov $2, %eax; incsspd %eax", X86_FEATURE_XEN_SHSTK
#endif
+#ifdef CONFIG_WAIT
call check_wakeup_from_wait
+#endif
ret_from_intr:
GET_CURRENT(bx)
testb $3, UREGS_cs(%rsp)
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index d7e79e752a..ab3f24cb4f 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -173,10 +173,14 @@ config HAS_VMAP
config LIBFDT
bool
+config WAIT
+ bool
+
config VM_EVENT
bool "Memory Access and VM events"
depends on HVM
default X86
+ select WAIT
help
Framework to configure memory access types for guests and receive
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 4fc0c15088..ef2c5ddd4e 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -61,7 +61,7 @@ obj-y += virtual_region.o
obj-$(CONFIG_VM_EVENT) += vm_event.o
obj-$(CONFIG_HAS_VMAP) += vmap.o
obj-y += vsprintf.o
-obj-y += wait.o
+obj-$(CONFIG_WAIT) += wait.o
obj-bin-y += warning.init.o
obj-y += xmalloc_tlsf.o
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 1268632344..f232f2731e 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -293,7 +293,9 @@ struct vcpu
/* Multicall information. */
struct mc_state mc_state;
+#ifdef CONFIG_WAIT
struct waitqueue_vcpu *waitqueue_vcpu;
+#endif
struct evtchn_fifo_vcpu *evtchn_fifo;
diff --git a/xen/include/xen/wait.h b/xen/include/xen/wait.h
index 1c68bc564b..d7d83adef1 100644
--- a/xen/include/xen/wait.h
+++ b/xen/include/xen/wait.h
@@ -49,11 +49,18 @@ do { \
} while (0)
/* Private functions. */
-int init_waitqueue_vcpu(struct vcpu *v);
-void destroy_waitqueue_vcpu(struct vcpu *v);
void prepare_to_wait(struct waitqueue_head *wq);
void wait(void);
void finish_wait(struct waitqueue_head *wq);
+
+#ifdef CONFIG_WAIT
+int init_waitqueue_vcpu(struct vcpu *v);
+void destroy_waitqueue_vcpu(struct vcpu *v);
void check_wakeup_from_wait(void);
+#else
+static inline int init_waitqueue_vcpu(struct vcpu *v) { return 0; }
+static inline void destroy_waitqueue_vcpu(struct vcpu *v) {}
+static inline void check_wakeup_from_wait(void) {}
+#endif
#endif /* __XEN_WAIT_H__ */
--
2.53.0On 11/02/2026 5:01 pm, Jason Andryuk wrote: > wait.c is only used by vm_event.c. Make CONFIG_VM_EVENT select > CONFIG_WAIT, and use CONFIG_WAIT to control building it. > > Provide stubs of functions called from common code. entry.S needs an > ifdef to hide the symbol from the assembly. > > Also conditionalize .waitqueue_vcpu in struct vcpu to save space. > > Signed-off-by: Jason Andryuk <jason.andryuk@amd.com> I'd really rather see the API/ABI changes required to purge wait.c entirely, but I guess this will do in the short term. Two things want further thought. First, because ARM uses per-vCPU stacks not per-pCPU stacks, it doesn't need this infrastructure in the first place, but it looks like it's still compiled in and half wired up. I suppose you don't notice because you compile out VM_EVENT on ARM too? Second CONFIG_WAIT isn't great name because there are many things it could be. I'd be tempted to just reuse CONFIG_VM_EVENT and go without CONFIG_WAIT. I do not want to see any new users of wait.c, and it will disappear at some point. ~Andrew
On 11.02.2026 18:30, Andrew Cooper wrote: > On 11/02/2026 5:01 pm, Jason Andryuk wrote: >> wait.c is only used by vm_event.c. Make CONFIG_VM_EVENT select >> CONFIG_WAIT, and use CONFIG_WAIT to control building it. >> >> Provide stubs of functions called from common code. entry.S needs an >> ifdef to hide the symbol from the assembly. >> >> Also conditionalize .waitqueue_vcpu in struct vcpu to save space. >> >> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com> > > I'd really rather see the API/ABI changes required to purge wait.c > entirely, but I guess this will do in the short term. > > Two things want further thought. > > First, because ARM uses per-vCPU stacks not per-pCPU stacks, it doesn't > need this infrastructure in the first place, but it looks like it's > still compiled in and half wired up. I suppose you don't notice because > you compile out VM_EVENT on ARM too? But if we want it compiled out altogether on Arm, ... > Second CONFIG_WAIT isn't great name because there are many things it > could be. I'd be tempted to just reuse CONFIG_VM_EVENT and go without > CONFIG_WAIT. I do not want to see any new users of wait.c, and it will > disappear at some point. ... don't we need a separate kconfig control, for it to be selected only on x86 (or for it to be dependent on x86, and then imply-ed)? Imo CONFIG_WAITQUEUE would be okay, as long as it won't have a prompt. We'd then simply want to prevent further select-s / imply-s to appear. Jan
On 2026-02-12 02:38, Jan Beulich wrote: > On 11.02.2026 18:30, Andrew Cooper wrote: >> On 11/02/2026 5:01 pm, Jason Andryuk wrote: >>> wait.c is only used by vm_event.c. Make CONFIG_VM_EVENT select >>> CONFIG_WAIT, and use CONFIG_WAIT to control building it. >>> >>> Provide stubs of functions called from common code. entry.S needs an >>> ifdef to hide the symbol from the assembly. >>> >>> Also conditionalize .waitqueue_vcpu in struct vcpu to save space. >>> >>> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com> >> >> I'd really rather see the API/ABI changes required to purge wait.c >> entirely, but I guess this will do in the short term. >> >> Two things want further thought. >> >> First, because ARM uses per-vCPU stacks not per-pCPU stacks, it doesn't >> need this infrastructure in the first place, but it looks like it's >> still compiled in and half wired up. I suppose you don't notice because >> you compile out VM_EVENT on ARM too? > > But if we want it compiled out altogether on Arm, ... > >> Second CONFIG_WAIT isn't great name because there are many things it >> could be. I'd be tempted to just reuse CONFIG_VM_EVENT and go without >> CONFIG_WAIT. I do not want to see any new users of wait.c, and it will >> disappear at some point. > > ... don't we need a separate kconfig control, for it to be selected only > on x86 (or for it to be dependent on x86, and then imply-ed)? Imo > CONFIG_WAITQUEUE would be okay, as long as it won't have a prompt. We'd > then simply want to prevent further select-s / imply-s to appear. ARM VM_EVENT=y won't link without wait.o. Undefined references to: wake_up_nr prepare_to_wait finish_wait destroy_waitqueue_head init_waitqueue_head So I think that points to re-using my original patch, but with either CONFIG_WAITQUEUE or CONFIG_VM_EVENT. Since CONFIG_VM_EVENT is the only user, and we don't want further uses, I would use that. But I am open to either. Regards, Jason
On Thu, Feb 12, 2026 at 02:14:58PM -0500, Jason Andryuk wrote: > On 2026-02-12 02:38, Jan Beulich wrote: > > On 11.02.2026 18:30, Andrew Cooper wrote: > > > On 11/02/2026 5:01 pm, Jason Andryuk wrote: > > > > wait.c is only used by vm_event.c. Make CONFIG_VM_EVENT select > > > > CONFIG_WAIT, and use CONFIG_WAIT to control building it. > > > > > > > > Provide stubs of functions called from common code. entry.S needs an > > > > ifdef to hide the symbol from the assembly. > > > > > > > > Also conditionalize .waitqueue_vcpu in struct vcpu to save space. > > > > > > > > Signed-off-by: Jason Andryuk <jason.andryuk@amd.com> > > > > > > I'd really rather see the API/ABI changes required to purge wait.c > > > entirely, but I guess this will do in the short term. > > > > > > Two things want further thought. > > > > > > First, because ARM uses per-vCPU stacks not per-pCPU stacks, it doesn't > > > need this infrastructure in the first place, but it looks like it's > > > still compiled in and half wired up. I suppose you don't notice because > > > you compile out VM_EVENT on ARM too? > > > > But if we want it compiled out altogether on Arm, ... > > > > > Second CONFIG_WAIT isn't great name because there are many things it > > > could be. I'd be tempted to just reuse CONFIG_VM_EVENT and go without > > > CONFIG_WAIT. I do not want to see any new users of wait.c, and it will > > > disappear at some point. > > > > ... don't we need a separate kconfig control, for it to be selected only > > on x86 (or for it to be dependent on x86, and then imply-ed)? Imo > > CONFIG_WAITQUEUE would be okay, as long as it won't have a prompt. We'd > > then simply want to prevent further select-s / imply-s to appear. > > ARM VM_EVENT=y won't link without wait.o. Undefined references to: > wake_up_nr > prepare_to_wait > finish_wait > destroy_waitqueue_head > init_waitqueue_head > > So I think that points to re-using my original patch, but with either > CONFIG_WAITQUEUE or CONFIG_VM_EVENT. Since CONFIG_VM_EVENT is the only > user, and we don't want further uses, I would use that. But I am open to > either. I think hiding behind CONFIG_VM_EVENT is better, we want to avoid new instances of waitqueue (at least in it's current state), so not sure it makes a lot of sense to add it under a different Kconfig option if our intention is for waitqueue to only be used with VM events. Thanks, Roger.
On 12.02.2026 20:14, Jason Andryuk wrote: > On 2026-02-12 02:38, Jan Beulich wrote: >> On 11.02.2026 18:30, Andrew Cooper wrote: >>> On 11/02/2026 5:01 pm, Jason Andryuk wrote: >>>> wait.c is only used by vm_event.c. Make CONFIG_VM_EVENT select >>>> CONFIG_WAIT, and use CONFIG_WAIT to control building it. >>>> >>>> Provide stubs of functions called from common code. entry.S needs an >>>> ifdef to hide the symbol from the assembly. >>>> >>>> Also conditionalize .waitqueue_vcpu in struct vcpu to save space. >>>> >>>> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com> >>> >>> I'd really rather see the API/ABI changes required to purge wait.c >>> entirely, but I guess this will do in the short term. >>> >>> Two things want further thought. >>> >>> First, because ARM uses per-vCPU stacks not per-pCPU stacks, it doesn't >>> need this infrastructure in the first place, but it looks like it's >>> still compiled in and half wired up. I suppose you don't notice because >>> you compile out VM_EVENT on ARM too? >> >> But if we want it compiled out altogether on Arm, ... >> >>> Second CONFIG_WAIT isn't great name because there are many things it >>> could be. I'd be tempted to just reuse CONFIG_VM_EVENT and go without >>> CONFIG_WAIT. I do not want to see any new users of wait.c, and it will >>> disappear at some point. >> >> ... don't we need a separate kconfig control, for it to be selected only >> on x86 (or for it to be dependent on x86, and then imply-ed)? Imo >> CONFIG_WAITQUEUE would be okay, as long as it won't have a prompt. We'd >> then simply want to prevent further select-s / imply-s to appear. > > ARM VM_EVENT=y won't link without wait.o. Undefined references to: > wake_up_nr > prepare_to_wait > finish_wait > destroy_waitqueue_head > init_waitqueue_head Hmm, okay, assuming that then also actually works, ... > So I think that points to re-using my original patch, but with either > CONFIG_WAITQUEUE or CONFIG_VM_EVENT. Since CONFIG_VM_EVENT is the only > user, and we don't want further uses, I would use that. ... please do. Jan
On 2026-02-11 12:30, Andrew Cooper wrote: > On 11/02/2026 5:01 pm, Jason Andryuk wrote: >> wait.c is only used by vm_event.c. Make CONFIG_VM_EVENT select >> CONFIG_WAIT, and use CONFIG_WAIT to control building it. >> >> Provide stubs of functions called from common code. entry.S needs an >> ifdef to hide the symbol from the assembly. >> >> Also conditionalize .waitqueue_vcpu in struct vcpu to save space. >> >> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com> > > I'd really rather see the API/ABI changes required to purge wait.c > entirely, but I guess this will do in the short term. > > Two things want further thought. > > First, because ARM uses per-vCPU stacks not per-pCPU stacks, it doesn't > need this infrastructure in the first place, but it looks like it's > still compiled in and half wired up. I suppose you don't notice because > you compile out VM_EVENT on ARM too? I was focused on x86, and didn't realize this was used by ARM. I think I noticed the lack of check_wakeup_from_wait() calls on ARM. What did I not notice? Are you saying wait.c should only be built for x86? > Second CONFIG_WAIT isn't great name because there are many things it > could be. I'd be tempted to just reuse CONFIG_VM_EVENT and go without > CONFIG_WAIT. I do not want to see any new users of wait.c, and it will > disappear at some point. Yes. I used CONFIG_WAIT since it matched wait.c. I considered CONFIG_WAITQUEUE, but went with the shorter option. Re-using CONFIG_VM_EVENT would be fine with me. I didn't use it in this submission since the waitqueue functionality is more generic. Regards, Jason
© 2016 - 2026 Red Hat, Inc.