> -----Original Message----- > From: Intel-wired-lan <[email protected]> On Behalf Of > Loktionov, Aleksandr > Sent: Wednesday, April 29, 2026 11:21 AM > To: Marcin Szycik <[email protected]>; intel-wired- > [email protected] > Cc: [email protected]; Greenwalt, Paul <[email protected]>; > Keller, Jacob E <[email protected]>; Kitszel, Przemyslaw > <[email protected]> > Subject: Re: [Intel-wired-lan] [PATCH iwl-next 3/3] virtchnl, iavf, ice, > i40e: add > extended generic VF capability flags > > > > > -----Original Message----- > > From: Intel-wired-lan <[email protected]> On Behalf > > Of Marcin Szycik > > Sent: Tuesday, April 28, 2026 4:37 PM > > To: [email protected] > > Cc: [email protected]; Greenwalt, Paul > > <[email protected]>; Keller, Jacob E > > <[email protected]>; Marcin Szycik > > <[email protected]>; Kitszel, Przemyslaw > > <[email protected]> > > Subject: [Intel-wired-lan] [PATCH iwl-next 3/3] virtchnl, iavf, ice, > > i40e: add extended generic VF capability flags > > > > VF capability flags in struct virtchnl_vf_resource::vf_cap_flags have > > all been used up, preventing new flags from being added. Note that > > despite not all bits being defined here, they are used by out-of-tree > > releases of Intel drivers, therefore cannot be taken. > > > > virtchnl message size and structure must remain unchanged to not break > > reverse compatibility, therefore the existing virtchnl structure > > cannot be extended with additional fields (e.g. flags2). vf_cap_flags > > type cannot be changed to a larger one for the same reason. > > > > Bit 2 of vf_cap_flags was reserved for exactly this case. Its presence > > in message initially sent from VF shall now signal that there are more > > capability flags to be parsed. If the PF driver acknowledges that via > > VIRTCHNL_OP_GET_VF_RESOURCES response, the VF will send a separate > > message: VIRTCHNL_OP_GET_VF_CAPS2, containing more capability flags. > > Note: this mechanism is similar for VIRTCHNL_OP_1588_PTP_GET_CAPS. > > > > The new message supports flexible size, so more flags can be added > > without any architectural changes. Care was taken to ensure that no > > out-of-bounds reads happen in case the bitmap is shorter in one of the > > drivers. > > > > The new message includes the original 32 bits too, for consistency and > > more straightforward parsing. > > > > Signed-off-by: Marcin Szycik <[email protected]> > > Reviewed-by: Przemek Kitszel <[email protected]> > > Reviewed-by: Jacob Keller <[email protected]> > > --- > > drivers/net/ethernet/intel/iavf/iavf.h | 19 ++- > > .../net/ethernet/intel/ice/virt/virtchnl.h | 2 + > > include/linux/intel/virtchnl.h | 55 ++++++- > > .../ethernet/intel/i40e/i40e_virtchnl_pf.c | 84 +++++++++++ > > drivers/net/ethernet/intel/iavf/iavf_main.c | 60 ++++++++ > > .../net/ethernet/intel/iavf/iavf_virtchnl.c | 138 > > +++++++++++++++++- > > .../net/ethernet/intel/ice/virt/allowlist.c | 6 + > > .../net/ethernet/intel/ice/virt/virtchnl.c | 86 +++++++++++ > > 8 files changed, 444 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/net/ethernet/intel/iavf/iavf.h > > b/drivers/net/ethernet/intel/iavf/iavf.h > > index 64576cba3a01..5d812b0a52a3 100644 > > --- a/drivers/net/ethernet/intel/iavf/iavf.h > > +++ b/drivers/net/ethernet/intel/iavf/iavf.h > > @@ -343,6 +343,7 @@ struct iavf_adapter { > > #define IAVF_FLAG_AQ_GET_SUPPORTED_RXDIDS BIT_ULL(42) > > #define IAVF_FLAG_AQ_GET_PTP_CAPS BIT_ULL(43) > > #define IAVF_FLAG_AQ_SEND_PTP_CMD BIT_ULL(44) > > ... > > > case VIRTCHNL_OP_UNKNOWN: > > default: > > dev_err(dev, "Unsupported opcode %d from VF %d\n", v_opcode, > > -- > > 2.49.0 > > Reviewed-by: Aleksandr Loktionov <[email protected]>
Tested-by: Rafal Romanowski <[email protected]>
