Re: [Intel-wired-lan] [PATCH iwl-next v3] libie: log more info when virtchnl fails

[Li Li]

On Thu, Apr 30, 2026 at 1:36 AM Loktionov, Aleksandr
<aleksandr.loktionov@xxxxxxxxx> wrote:
>
>
>
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@xxxxxxxxxx> On Behalf
> > Of Li Li via Intel-wired-lan
> > Sent: Wednesday, April 29, 2026 10:41 PM
> > To: Nguyen, Anthony L <anthony.l.nguyen@xxxxxxxxx>; Kitszel,
> > Przemyslaw <przemyslaw.kitszel@xxxxxxxxx>; David S. Miller
> > <davem@xxxxxxxxxxxxx>; Jakub Kicinski <kuba@xxxxxxxxxx>; Eric Dumazet
> > <edumazet@xxxxxxxxxx>; intel-wired-lan@xxxxxxxxxxxxxxxx
> > Cc: netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; David
> > Decotigny <decot@xxxxxxxxxx>; Singhai, Anjali
> > <anjali.singhai@xxxxxxxxx>; Samudrala, Sridhar
> > <sridhar.samudrala@xxxxxxxxx>; Brian Vazquez <brianvv@xxxxxxxxxx>; Li
> > Li <boolli@xxxxxxxxxx>; Tantilov, Emil S <emil.s.tantilov@xxxxxxxxx>
> > Subject: [Intel-wired-lan] [PATCH iwl-next v3] libie: log more info
> > when virtchnl fails
> >
> > Virtchnl failures can be hard to debug without logs. Logging the
> > details of virtchnl transactions can be useful for debugging virtchnl-
> > related issues.
> >
> > Tested: Built & booted on a test machine and synthetically produced a
> > virtual failure to produce the following log:
> >
> > idpf 0000:01:00.0: Non-zero virtchnl ret val (msg op: 1, ret val: 6,
> > data_len: 8); xn id: 0, cookie: 0
> > idpf 0000:01:00.0: Transaction failed (op 1, xn state:
> > 3, id: 0, cookie: 0, size: 8)
> >
> > Signed-off-by: Li Li <boolli@xxxxxxxxxx>
> > ---
> > v3:
> >  - Use dev_err_ratelimited in both logs.
> >  - Move log placement to after virtchnl field validation.
> >  - Remove redundant op/cookie fields since they were validated.
> > v2:
> >  - Use dev_warn_ratelimited instead of dev_notice_ratelimited based on
> >    reviewer feedback.
> >
> >  drivers/net/ethernet/intel/libie/controlq.c | 13 +++++++++++++
> >  1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/intel/libie/controlq.c
> > b/drivers/net/ethernet/intel/libie/controlq.c
> > index ebc05355e39d..ceca8a076d79 100644
> > --- a/drivers/net/ethernet/intel/libie/controlq.c
> > +++ b/drivers/net/ethernet/intel/libie/controlq.c
> > @@ -766,6 +766,14 @@ libie_ctlq_xn_process_recv(struct
> > libie_ctlq_xn_recv_params *params,
> >           msg_cookie != xn->cookie)
> >               return false;
> >
> > +     if (ctlq_msg->chnl_retval) {
> > +             dev_err_ratelimited(
> > +                     params->ctlq->dev,
> > +                     "Non-zero virtchnl ret val (msg op: %u, ret val:
> > %u, data_len: %u); xn id: %u, cookie: %u\n",
> > +                     ctlq_msg->chnl_opcode, ctlq_msg->chnl_retval,
> > +                     ctlq_msg->data_len, xn->index, xn->cookie);
> 'virtchnl ret val' 'ret val:' looks like a duplication in dmesg.

Let me send out v4 to simplify it.

>
>
> > +     }
> > +
> >       spin_lock(&xn->xn_lock);
> >       if (xn->state != LIBIE_CTLQ_XN_ASYNC &&
> >           xn->state != LIBIE_CTLQ_XN_WAITING) { @@ -1011,6 +1019,11
> > @@ int libie_ctlq_xn_send(struct libie_ctlq_xn_send_params *params)
> >               params->recv_mem = xn->recv_mem;
> >               break;
> >       default:
> > +             dev_err_ratelimited(
> > +                     params->ctlq->dev,
> > +                     "Transaction failed (op %u, xn state: %d, id: %u,
> > cookie: %u, size: %zu)\n",
> > +                     params->chnl_opcode, xn->state, xn->index, xn-
> > >cookie,
> > +                     xn->recv_mem.iov_len);
> Probably %u fits better for enums than %d, what do you think?

Sure, let me use %u in v4.

>
> >               ret = -EBADMSG;
> >               break;
> >       }
> > --
> > 2.54.0.545.g6539524ca2-goog
>