Re: [PATCH v3 1/6] argo: lower level of noisy connection-refused log

[Daniel Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

From:  <dmukhin@xxxxxxxx>
To: "Daniel P. Smith"<dpsmith@xxxxxxxxxxxxxxxxxxxx>
Cc: <dmukhin@xxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>, 
<andrew.cooper3@xxxxxxxxxx>, <anthony.perard@xxxxxxxxxx>, <jbeulich@xxxxxxxx>, 
<julien@xxxxxxx>, <michal.orzel@xxxxxxx>, <roger.pau@xxxxxxxxxx>, 
<sstabellini@xxxxxxxxxx>, <christopher.w.clark@xxxxxxxxx>, "Mykola 
Kvach"<mykola_kvach@xxxxxxxx>
Date: Mon, 08 Jun 2026 21:05:45 -0400
Subject: Re: [PATCH v3 1/6] argo: lower level of noisy connection-refused log

 > On Mon, Jun 08, 2026 at 03:54:51PM -0400, Daniel P. Smith wrote: 
 > > 
 > > 
 > > On 5/26/26 5:58 PM, dmukhin@xxxxxxxx wrote: 
 > > > From: Denis Mukhin <dmukhin@xxxxxxxx> 
 > > > 
 > > > Switch the log line to argo_dprintk() so it is enabled only in debug 
 > > > environments, as it can spam the logs when a dom0 service using the Argo 
 > > > hypercall tries to communicate with a domain that is still starting up. 
 > > > 
 > > > Note that this also lowers the log level to debug when the 
 > > > argo_dprintk() 
 > > > facility is enabled. 
 > > > 
 > > > Signed-off-by: Denis Mukhin <dmukhin@xxxxxxxx> 
 > > > Reviewed-by: Mykola Kvach <mykola_kvach@xxxxxxxx> 
 > > > --- 
 > > > Changes since v2: 
 > > > - updated commit message 
 > > > --- 
 > > >   xen/common/argo.c | 7 +++---- 
 > > >   1 file changed, 3 insertions(+), 4 deletions(-) 
 > > > 
 > > > diff --git a/xen/common/argo.c b/xen/common/argo.c 
 > > > index 28626e00a8cb..98a3db7fd070 100644 
 > > > --- a/xen/common/argo.c 
 > > > +++ b/xen/common/argo.c 
 > > > @@ -2034,10 +2034,9 @@ sendv(struct domain *src_d, xen_argo_addr_t 
 > > > *src_addr, 
 > > >                                           src_id.domain_id); 
 > > >       if ( !ring_info ) 
 > > >       { 
 > > > -        gprintk(XENLOG_ERR, 
 > > > -                "argo: vm%u connection refused, src (vm%u:%x) dst 
 > > > (vm%u:%x)\n", 
 > > > -                current->domain->domain_id, src_id.domain_id, 
 > > > src_id.aport, 
 > > > -                dst_addr->domain_id, dst_addr->aport); 
 > > > +        argo_dprintk("vm%u connection refused, src (vm%u:%x) dst 
 > > > (vm%u:%x)\n", 
 > > > +                     current->domain->domain_id, src_id.domain_id, 
 > > > src_id.aport, 
 > > > +                     dst_addr->domain_id, dst_addr->aport); 
 > > >           ret = -ECONNREFUSED; 
 > > >       } 
 > > 
 > > My apologies but this is not the wisest approach, hitting this is a real 
 > > error and shouldn't be getting silenced. If you are seeing a lot of these 
 > > messages, I would suggest asking yourself why. Without further context on 
 > > how you are using it, one suggesting is perhaps your connection model 
 > > might 
 > > need to be revisited. 
 >  
 > Thanks for the feedback! 
 >  

Not a problem and you're welcome.

 > The reason I wrote this patch is because there can be a lot of those 
 > messages 
 > from a real domU which is in a boot loop and/or boots for a significant 
 > amount 
 > of time. 
 >  
 > With -ECONNREFUSED propagated back to the caller having Xen logging the 
 > state 
 > of each sendv() with XENLOG_ERR on the shared (dom0) diag console can be a 
 > bit 
 > problematic. 
 >  
 > Yes, I understand that programs issuing the Argo hypercall could be 
 > rewritten 
 > in a particular way so that the Argo hypercall is issued only if the domain 
 > is 
 > up and Argo on the other side is initialized and, ideally, domain should not 
 > be boot-looping... 
 >  
 > However, I think, that hypervisor should not depend on assumptions made in 
 > the 
 > userspace (e.g. retry/logging policy). 
 >  
 > De-prioritizing the logline from XENLOG_ERR to XENLOG_DEBUG can be another 
 > potential solution. 


Please look at my response to Jason, this is essentially one of the cases for 
which the notify op exists.

v/r,
dps