[PATCH v1 1/1] net/iavf: fix large VF IRQ mapping

[Burakov, Anatoly]

On 5/8/2026 11:16 AM, Morten Brørup wrote:
>> From: Burakov, Anatoly [mailto:anatoly.burakov at intel.com]
>> Sent: Thursday, 7 May 2026 10.09
>>
>> On 5/6/2026 5:58 PM, David Marchand wrote:
>>> On Wed, 6 May 2026 at 16:07, Anatoly Burakov
>> <anatoly.burakov at intel.com> wrote:
>>>>
>>>> The PF will check buffer size for being too big, and the chunk
>> sizing code
>>>> correctly calls that out. However, the size was actually still too
>> big
>>>> because `struct virtchnl_queue_vector_maps` already had one queue
>> vector
>>>> as part of its definition, so `chunk_sz` was too big by 1.
>>>>
>>>> Fixes: 292d3b781ac4 ("net/iavf: replace unnecessary hugepage memory
>> allocations")
>>>>
>>>> Signed-off-by: Anatoly Burakov <anatoly.burakov at intel.com>
>>>> ---
>>>>    drivers/net/intel/iavf/iavf_vchnl.c | 2 +-
>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/intel/iavf/iavf_vchnl.c
>> b/drivers/net/intel/iavf/iavf_vchnl.c
>>>> index c2f340db81..dd09b0fa61 100644
>>>> --- a/drivers/net/intel/iavf/iavf_vchnl.c
>>>> +++ b/drivers/net/intel/iavf/iavf_vchnl.c
>>>> @@ -1528,7 +1528,7 @@ iavf_config_irq_map_lv_chunk(struct
>> iavf_adapter *adapter,
>>>>
>>>>           /* for some reason PF side checks for buffer being too big,
>> so adjust it down */
>>>
>>> The comment above can be removed?
>>
>> No, it's still relevant, because it refers to the fact that we're
>> adjusting the total length downwards as opposed to leaving it at max
>> size.
>>
>>>
>>>>           buf_len = sizeof(struct virtchnl_queue_vector_maps) +
>>>> -                 sizeof(struct virtchnl_queue_vector) * chunk_sz;
>>>> +                 sizeof(struct virtchnl_queue_vector) * (chunk_sz -
>> 1);
>>>
>>> - did you make sure you did not break compat with previous version of
>>> Intel out of tree PF driver (since this concerns configuring "Large
>>> VF")?
>>
>> The commit in question *did* break things with previous out of tree PF
>> driver. This commit fixes the breakage introduced in that commit. The
>> commit being fixed was a refactor, which specified size as N-1.
>>
>>>
>>> - all those virtchnl list struct have the same elems[1] issue.
>>> Kernel side did some cleanups some time ago, maybe time for DPDK to
>> do
>>> the same...?
>>>
>>
>> Yes, it is indeed time to do the same, but not as part of this
>> patchset,
>> and not before the base driver code is updated to do the same. There is
>> some background work happening on that front already, but there are a
>> lot of dependencies and moving parts, so we can't just change this
>> willy
>> nilly.
> 
> Is there a timeline for this fix?
> 

No specific timeline, unfortunately.

-- 
Thanks,
Anatoly