evtchn_bind_interdomain() sets the notification on the local port to
handle the lost notification on remote unbound port.

Static event-channel will be created during domain creation, there is no
need to set the notification as remote domain is not alive.

Signed-off-by: Rahul Singh <rahul.singh@arm.com>
---
 xen/common/event_channel.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index cedc98ccaf..420d18b986 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -435,8 +435,13 @@ int evtchn_bind_interdomain(evtchn_bind_interdomain_t *bind, struct domain *ld,
     /*
      * We may have lost notifications on the remote unbound port. Fix that up
      * here by conservatively always setting a notification on the local port.
+     *
+     * There is no need to set the notification if event channel is created in
+     * Xen because domain is not created at this time and no chance of lost
+     * notification.
      */
-    evtchn_port_set_pending(ld, lchn->notify_vcpu_id, lchn);
+    if ( !is_static )
+        evtchn_port_set_pending(ld, lchn->notify_vcpu_id, lchn);
 
     double_evtchn_unlock(lchn, rchn);
 
-- 
2.25.1

On 22.06.2022 16:38, Rahul Singh wrote:
> evtchn_bind_interdomain() sets the notification on the local port to
> handle the lost notification on remote unbound port.
> 
> Static event-channel will be created during domain creation, there is no
> need to set the notification as remote domain is not alive.

So _both_ sides are (to be) created by Xen? I think this wants to be
an optimization _after_ the new users have been introduced; I don't
think the excess notification is a problem? That way one can actually
verify that the uses are as (at this point) guessed.

Also the title shouldn't say (just) "don't" because it skips the step
only conditionally.

Jan