Evtchn fifos are not needed on smaller systems; the older interface is
lightweight and sufficient. Make it possible to disable evtchn fifo.

Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>

diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index a6aa2c5c14..14d82923c5 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -23,6 +23,16 @@ config GRANT_TABLE
 
 	  If unsure, say Y.
 
+config EVTCHN_FIFO
+	bool "Event Channel Fifo support" if EXPERT
+	default y
+	help
+	  The Event channel Fifo extends support for event channels
+	  beyond 1024 event channels for 32-bit guests and 4096 for
+	  64-bit guests.
+
+	  If unsure, say Y.
+
 config PDX_COMPRESSION
 	bool "PDX (Page inDeX) compression" if EXPERT && !X86 && !RISCV
 	default ARM || PPC
diff --git a/xen/common/Makefile b/xen/common/Makefile
index ac23120d7d..9da8a7244d 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_IOREQ_SERVER) += dm.o
 obj-y += domain.o
 obj-y += event_2l.o
 obj-y += event_channel.o
-obj-y += event_fifo.o
+obj-$(CONFIG_EVTCHN_FIFO) += event_fifo.o
 obj-$(CONFIG_GRANT_TABLE) += grant_table.o
 obj-y += guestcopy.o
 obj-y += gzip/
diff --git a/xen/common/event_channel.h b/xen/common/event_channel.h
index 45219ca67c..a778ae775b 100644
--- a/xen/common/event_channel.h
+++ b/xen/common/event_channel.h
@@ -45,12 +45,27 @@ void evtchn_2l_init(struct domain *d);
 
 /* FIFO */
 
+#ifdef CONFIG_EVTCHN_FIFO
 struct evtchn_init_control;
 struct evtchn_expand_array;
 
 int evtchn_fifo_init_control(struct evtchn_init_control *init_control);
 int evtchn_fifo_expand_array(const struct evtchn_expand_array *expand_array);
 void evtchn_fifo_destroy(struct domain *d);
+#else
+static inline int evtchn_fifo_init_control(struct evtchn_init_control *init_control)
+{
+    return -EOPNOTSUPP;
+}
+static inline int evtchn_fifo_expand_array(const struct evtchn_expand_array *expand_array)
+{
+    return -EOPNOTSUPP;
+}
+static inline void evtchn_fifo_destroy(struct domain *d)
+{
+    return;
+}
+#endif /* CONFIG_EVTCHN_FIFO */
 
 /*
  * Local variables:

On 19.03.2025 00:40, Stefano Stabellini wrote:
> Evtchn fifos are not needed on smaller systems; the older interface is
> lightweight and sufficient. Make it possible to disable evtchn fifo.
> 
> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>

Let me ask a more general question, before considering whether to ack:
When kconfig was introduced into Xen, the expectation was (iirc) that
we wouldn't grow its use to the fine grained granularity that it has
been having in Linux. The more build-time controls we have, the harder
it is to know whether a certain piece of code was actually included in
a build someone, say, reports a problem with. Are we knowingly moving
away from that earlier position? evtchn_fifo.c isn't actually that
much code to exclude, after all ...

Jan

On Thu, 20 Mar 2025, Jan Beulich wrote:
> On 19.03.2025 00:40, Stefano Stabellini wrote:
> > Evtchn fifos are not needed on smaller systems; the older interface is
> > lightweight and sufficient. Make it possible to disable evtchn fifo.
> > 
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
> 
> Let me ask a more general question, before considering whether to ack:
> When kconfig was introduced into Xen, the expectation was (iirc) that
> we wouldn't grow its use to the fine grained granularity that it has
> been having in Linux. The more build-time controls we have, the harder
> it is to know whether a certain piece of code was actually included in
> a build someone, say, reports a problem with. Are we knowingly moving
> away from that earlier position? evtchn_fifo.c isn't actually that
> much code to exclude, after all ...


I think we need to be more flexible with build-time controls. The extent
to which we should be flexible is an interesting discussion to have.

However, this patch is not for code size. This code causes unnecessary
runtime anonymous memory allocations, which are highly undesirable. In
fact, it is the primary source of such allocations. Additionally, it
exposes an extra interface to the guest, which is also undesirable
unless necessary.

In other words, the issue is not the size of the code, but its impact.

On 21.03.2025 22:30, Stefano Stabellini wrote:
> On Thu, 20 Mar 2025, Jan Beulich wrote:
>> On 19.03.2025 00:40, Stefano Stabellini wrote:
>>> Evtchn fifos are not needed on smaller systems; the older interface is
>>> lightweight and sufficient. Make it possible to disable evtchn fifo.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
>>
>> Let me ask a more general question, before considering whether to ack:
>> When kconfig was introduced into Xen, the expectation was (iirc) that
>> we wouldn't grow its use to the fine grained granularity that it has
>> been having in Linux. The more build-time controls we have, the harder
>> it is to know whether a certain piece of code was actually included in
>> a build someone, say, reports a problem with. Are we knowingly moving
>> away from that earlier position? evtchn_fifo.c isn't actually that
>> much code to exclude, after all ...
> 
> 
> I think we need to be more flexible with build-time controls. The extent
> to which we should be flexible is an interesting discussion to have.
> 
> However, this patch is not for code size. This code causes unnecessary
> runtime anonymous memory allocations, which are highly undesirable. In
> fact, it is the primary source of such allocations. Additionally, it
> exposes an extra interface to the guest, which is also undesirable
> unless necessary.
> 
> In other words, the issue is not the size of the code, but its impact.

This may help if it was said in the description.

Jan