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

[Jason Andryuk <jason.andryuk@xxxxxxx>]

On 2026-06-08 15:54, 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.
-ECONNREFUSED is still returned, and that is the important part, I think?

While gprintk(), it is trivially guest triggerable, so I think it wants 
to be a debug message like this change made it.  As a comparison, errors 
in event_channel.c are gdprintk().
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.
There isn't a way to know if a port is available without polling?

Regards,
Jason