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

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

[Anatoly Burakov]

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@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 */
 	buf_len = sizeof(struct virtchnl_queue_vector_maps) +
-		  sizeof(struct virtchnl_queue_vector) * chunk_sz;
+		  sizeof(struct virtchnl_queue_vector) * (chunk_sz - 1);
 
 	args.ops = VIRTCHNL_OP_MAP_QUEUE_VECTOR;
 	args.in_args = (u8 *)map_info;
-- 
2.47.3

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

[David Marchand]

On Wed, 6 May 2026 at 16:07, Anatoly Burakov <anatoly.burakov@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@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?

>         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")?

- 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...?


-- 
David Marchand

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

[Burakov, Anatoly]

On 5/6/2026 5:58 PM, David Marchand wrote:
> On Wed, 6 May 2026 at 16:07, Anatoly Burakov <anatoly.burakov@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@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.

-- 
Thanks,
Anatoly

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

[Morten Brørup]

> From: Burakov, Anatoly [mailto:anatoly.burakov@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@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@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?

With the performance improved rte_memcpy() patch [1], one of the CI compilers complains about buffer overflows when writing beyond these undersize arrays [2].
And I'd like to see the performance improved rte_memcpy() merged in 26.07.

[1]: https://patchwork.dpdk.org/project/dpdk/patch/20260429103548.220354-1-mb@smartsharesystems.com/
[2]: https://github.com/ovsrobot/dpdk/actions/runs/25104438552/job/74968218420

-Morten

Re: [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@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@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@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

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

[Morten Brørup]

> From: Burakov, Anatoly [mailto:anatoly.burakov@intel.com]
> Sent: Friday, 22 May 2026 11.46
> 
> On 5/8/2026 11:16 AM, Morten Brørup wrote:
> >> From: Burakov, Anatoly [mailto:anatoly.burakov@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@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@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.

The drivers were very recently updated to use memcpy() instead of rte_memcpy(), so now we can enable stringop-overflow warnings in rte_memcpy().
What really annoyed me was the need to disable these warnings in a general library function due to some drivers.

Since this problem has now been resolved, and the scope of the elems[1] problem has shrunk from system-wide to Intel drivers only, I'm not that concerned about timeline anymore. ;-)

-Morten

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

[Morten Brørup]

> From: Morten Brørup
> Sent: Friday, 8 May 2026 11.16
> 
> > From: Burakov, Anatoly [mailto:anatoly.burakov@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@intel.com> wrote:
> > >>
> > >
> > > - 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?
> 
> With the performance improved rte_memcpy() patch [1], one of the CI
> compilers complains about buffer overflows when writing beyond these
> undersize arrays [2].
> And I'd like to see the performance improved rte_memcpy() merged in
> 26.07.

With v10 of the rte_memcpy() patch [3], I have reverted the removal of the workaround that ignores stringop-overflow warnings in rte_memcpy(), so the patch doesn't depend on fixing the drivers.

Please take note to remove the workaround from rte_memcpy() when the flex array issue in the drivers - using elems[1] instead of elems[] - has been fixed.
Not ignoring buffer overflows in rte_memcpy() might help reveal bugs elsewhere.

Alternatively, move the workaround from rte_memcpy.h to the driver code requiring the workaround.

> 
> [1]:
> https://patchwork.dpdk.org/project/dpdk/patch/20260429103548.220354-1-
> mb@smartsharesystems.com/
> [2]:
> https://github.com/ovsrobot/dpdk/actions/runs/25104438552/job/749682184
> 20

[3]: https://patchwork.dpdk.org/project/dpdk/patch/20260508095827.53587-1-mb@smartsharesystems.com/

> 
> -Morten

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

[Bruce Richardson]

On Fri, May 08, 2026 at 12:16:01PM +0200, Morten Brørup wrote:
> > From: Morten Brørup
> > Sent: Friday, 8 May 2026 11.16
> > 
> > > From: Burakov, Anatoly [mailto:anatoly.burakov@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@intel.com> wrote:
> > > >>
> > > >
> > > > - 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?
> > 
> > With the performance improved rte_memcpy() patch [1], one of the CI
> > compilers complains about buffer overflows when writing beyond these
> > undersize arrays [2].
> > And I'd like to see the performance improved rte_memcpy() merged in
> > 26.07.
> 
> With v10 of the rte_memcpy() patch [3], I have reverted the removal of the workaround that ignores stringop-overflow warnings in rte_memcpy(), so the patch doesn't depend on fixing the drivers.
> 
> Please take note to remove the workaround from rte_memcpy() when the flex array issue in the drivers - using elems[1] instead of elems[] - has been fixed.
> Not ignoring buffer overflows in rte_memcpy() might help reveal bugs elsewhere.
> 
Actually, I'm more wondering if we really need to use rte_memcpy in our
drivers. Any use of memcpy is likely on the control path, and not
performance critical enough to warrant use of anything but the built-in
memcpy.

/Bruce

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

[Bruce Richardson]

On Wed, May 06, 2026 at 03:07:03PM +0100, Anatoly Burakov 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@intel.com>
> ---

Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Although there is discussion on-list about this patch, none of it concerns
this patch being wrong in itself, but rather future cleanup work done.
Therefore, I'm considering this patch for merge to next-net-intel shortly.

/Bruce

>  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 */
>  	buf_len = sizeof(struct virtchnl_queue_vector_maps) +
> -		  sizeof(struct virtchnl_queue_vector) * chunk_sz;
> +		  sizeof(struct virtchnl_queue_vector) * (chunk_sz - 1);
>  
>  	args.ops = VIRTCHNL_OP_MAP_QUEUE_VECTOR;
>  	args.in_args = (u8 *)map_info;
> -- 
> 2.47.3
> 

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

[Bruce Richardson]

On Tue, May 19, 2026 at 05:12:28PM +0100, Bruce Richardson wrote:
> On Wed, May 06, 2026 at 03:07:03PM +0100, Anatoly Burakov 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@intel.com>
> > ---
> 
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> 
Applied to next-net-intel.
Thanks,
/Bruce