qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Jason Wang <jasowang@redhat.com>
Cc: qemu-devel@nongnu.org, richard.henderson@linaro.org,
	 Bin Meng <bmeng@tinylab.org>
Subject: Re: [PULL 02/15] hw/net: e1000: Remove the logic of padding short frames in the receive path
Date: Tue, 28 Oct 2025 15:10:00 +0000	[thread overview]
Message-ID: <CAFEAcA_=dzzvbABCqt9mo70-e+c9FuVq0fr8_NPN67LSfv_=cQ@mail.gmail.com> (raw)
In-Reply-To: <20230707090628.2210346-3-jasowang@redhat.com>

On Fri, 7 Jul 2023 at 10:06, Jason Wang <jasowang@redhat.com> wrote:
>
> From: Bin Meng <bmeng@tinylab.org>
>
> Now that we have implemented unified short frames padding in the
> QEMU networking codes, remove the same logic in the NIC codes.
>
> This actually reverts commit 78aeb23eded2d0b765bf9145c71f80025b568acd.
>
> Signed-off-by: Bin Meng <bmeng@tinylab.org>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
>  hw/net/e1000.c | 11 +----------
>  1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index aae5f0b..093c2d4 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -888,7 +888,6 @@ e1000_receive_iov(NetClientState *nc, const struct iovec *iov, int iovcnt)
>      uint16_t vlan_special = 0;
>      uint8_t vlan_status = 0;
>      uint8_t min_buf[ETH_ZLEN];
> -    struct iovec min_iov;
>      uint8_t *filter_buf = iov->iov_base;
>      size_t size = iov_size(iov, iovcnt);
>      size_t iov_ofs = 0;
> @@ -905,15 +904,7 @@ e1000_receive_iov(NetClientState *nc, const struct iovec *iov, int iovcnt)
>          return 0;
>      }
>
> -    /* Pad to minimum Ethernet frame length */
> -    if (size < sizeof(min_buf)) {
> -        iov_to_buf(iov, iovcnt, 0, min_buf, size);
> -        memset(&min_buf[size], 0, sizeof(min_buf) - size);
> -        min_iov.iov_base = filter_buf = min_buf;
> -        min_iov.iov_len = size = sizeof(min_buf);
> -        iovcnt = 1;
> -        iov = &min_iov;
> -    } else if (iov->iov_len < MAXIMUM_ETHERNET_HDR_LEN) {
> +    if (iov->iov_len < MAXIMUM_ETHERNET_HDR_LEN) {
>          /* This is very unlikely, but may happen. */
>          iov_to_buf(iov, iovcnt, 0, min_buf, MAXIMUM_ETHERNET_HDR_LEN);
>          filter_buf = min_buf;

Hi; I'm investigating https://gitlab.com/qemu-project/qemu/-/issues/3043
and part of the problem seems to be this commit.

The repro case puts the e1000 into loopback mode, and then makes
the e1000 send out a zero-sized packet, which the net/ code feeds
back into the e1000's receive path. This then falls over because
the code in e1000_receive_iov() is not expecting a zero length iov
and walks off the end of the iov. Before this code was removed,
we would have padded the packet out to the minimum frame length.

If the idea is that ethernet device models can now assume
the packet is not short, who is responsible for ensuring
this for cases like loopback? Is it a bug in the e1000
transmit path? Or should the net core code be padding?
Is there somewhere we can conveniently assert that we
really did do the padding so that other cases which got
missed at least assert rather than walking off buffers?

thanks
-- PMM


  reply	other threads:[~2025-10-28 15:11 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-07  9:06 [PULL 00/15] Net patches Jason Wang
2023-07-07  9:06 ` [PULL 01/15] virtio-net: correctly report maximum tx_queue_size value Jason Wang
2023-07-07  9:06 ` [PULL 02/15] hw/net: e1000: Remove the logic of padding short frames in the receive path Jason Wang
2025-10-28 15:10   ` Peter Maydell [this message]
2023-07-07  9:06 ` [PULL 03/15] hw/net: vmxnet3: " Jason Wang
2023-07-07  9:06 ` [PULL 04/15] hw/net: i82596: " Jason Wang
2023-07-07  9:06 ` [PULL 05/15] hw/net: ne2000: " Jason Wang
2023-07-07  9:06 ` [PULL 06/15] hw/net: pcnet: " Jason Wang
2023-07-07  9:06 ` [PULL 07/15] hw/net: rtl8139: " Jason Wang
2023-07-07  9:06 ` [PULL 08/15] hw/net: sungem: " Jason Wang
2023-07-07  9:06 ` [PULL 09/15] hw/net: sunhme: " Jason Wang
2023-07-07  9:06 ` [PULL 10/15] hw/net: ftgmac100: Drop the small packet check " Jason Wang
2023-07-07  9:06 ` [PULL 11/15] net: socket: prepare to cleanup net_init_socket() Jason Wang
2023-07-07  9:06 ` [PULL 12/15] net: socket: move fd type checking to its own function Jason Wang
2023-07-07  9:06 ` [PULL 13/15] net: socket: remove net_init_socket() Jason Wang
2023-07-07  9:06 ` [PULL 14/15] e1000e: Add ICR clearing by corresponding IMS bit Jason Wang
2023-07-07  9:06 ` [PULL 15/15] igb: Remove obsolete workaround for Windows Jason Wang
2023-07-07 19:20 ` [PULL 00/15] Net patches Richard Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFEAcA_=dzzvbABCqt9mo70-e+c9FuVq0fr8_NPN67LSfv_=cQ@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=bmeng@tinylab.org \
    --cc=jasowang@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).