From: Marcelo Manzo <marcelomanzo@gmail.com>
To: qemu-devel@nongnu.org, qemu-arm@nongnu.org
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Philippe Mathieu-Daudé" <philmd@oss.qualcomm.com>,
"Marcelo Manzo" <marcelomanzo@gmail.com>,
"Philippe Mathieu-Daudé" <philmd@mailo.com>,
"Jason Wang" <jasowangio@gmail.com>
Subject: [PATCH v2 16/19] hw/net/bcm2838_genet: fix bogus RX checksum reporting
Date: Tue, 11 Aug 2026 10:35:53 -0400 [thread overview]
Message-ID: <20260811143557.7862-17-marcelomanzo@gmail.com> (raw)
In-Reply-To: <20260811143557.7862-1-marcelomanzo@gmail.com>
bcm2838_genet_rdma() reported the received frame's IPv4 header
checksum (in host byte order) as the descriptor's rx_csum value.
The guest driver's CHECKSUM_COMPLETE path expects a running checksum
over the L4 payload there, not the L3 header checksum, so the
mismatch made the guest reject otherwise-valid inbound packets
("hw csum failure" in dmesg, from bcmgenet_rx_poll()), breaking
DHCP and general connectivity intermittently.
Report no hardware-computed checksum instead (rx_csum = 0), which
makes the guest fall back to verifying checksums in software; this
succeeds since the packet data itself was never corrupted. Drop the
eth_get_protocols() call and its output variables along with it,
since isip4/ip4hdr_info were only ever used to compute the checksum
value being removed here.
Confirmed with the guest booted repeatedly: "hw csum failure" no
longer appears in dmesg, and ping to the gateway succeeds with 0%
loss.
Signed-off-by: Marcelo Manzo <marcelomanzo@gmail.com>
---
hw/net/bcm2838_genet.c | 27 ++++++++++++---------------
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/hw/net/bcm2838_genet.c b/hw/net/bcm2838_genet.c
index dfdc5ac728..ccf3c2fef0 100644
--- a/hw/net/bcm2838_genet.c
+++ b/hw/net/bcm2838_genet.c
@@ -828,12 +828,6 @@ static ssize_t bcm2838_genet_rdma(BCM2838GenetState *s, uint32_t ring_idx,
MemTxResult mem_tx_result = MEMTX_OK;
uint8_t *frame_buf = dma_buf + sizeof(BCM2838GenetXmitStatus) + 2;
BCM2838GenetXmitStatus *xmit_status = (BCM2838GenetXmitStatus *)dma_buf;
- struct iovec iov;
- bool isip4, isip6;
- size_t l3hdr_off, l4hdr_off, l5hdr_off;
- eth_ip6_hdr_info ip6hdr_info;
- eth_ip4_hdr_info ip4hdr_info;
- eth_l4_hdr_info l4hdr_info;
bool crc_fwd = FIELD_EX32(s->regs.umac.cmd, GENET_UMAC_CMD, CRC_FWD);
size_t buflength;
@@ -844,12 +838,6 @@ static ssize_t bcm2838_genet_rdma(BCM2838GenetState *s, uint32_t ring_idx,
}
memcpy(frame_buf, buf + len, l);
- iov.iov_base = frame_buf;
- iov.iov_len = l;
- eth_get_protocols(&iov, 1, 0,
- &isip4, &isip6,
- &l3hdr_off, &l4hdr_off, &l5hdr_off,
- &ip6hdr_info, &ip4hdr_info, &l4hdr_info);
len += l;
@@ -875,10 +863,19 @@ static ssize_t bcm2838_genet_rdma(BCM2838GenetState *s, uint32_t ring_idx,
MULTICAST,
!!is_packet_multicast(frame_buf, l));
+ /*
+ * Report no hardware-computed checksum. The IP header's own
+ * checksum was previously (incorrectly) stored here, but the
+ * guest's CHECKSUM_COMPLETE path expects a running checksum over
+ * the L4 payload, not the L3 header checksum -- and it was stored
+ * in host byte order besides. That mismatch was causing the guest
+ * to reject otherwise-valid inbound packets ("hw csum failure" in
+ * dmesg, tied to bcmgenet_rx_poll), breaking DHCP/connectivity
+ * intermittently. Leaving this at 0 makes the guest fall back to
+ * verifying checksums itself in software, which succeeds since the
+ * packet data itself is intact.
+ */
xmit_status->rx_csum = 0;
- if (isip4) {
- xmit_status->rx_csum = ip4hdr_info.ip4_hdr.ip_sum;
- }
xmit_status->length_status = desc->length_status;
mem_tx_result = address_space_write(&s->dma_as, dma_buf_addr,
--
2.47.1
next prev parent reply other threads:[~2026-08-11 14:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 14:35 [PATCH v2 00/19] hw/arm/raspi4b: working PCIe and GENET (real networking) Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 01/19] hw/arm/bcm2838_pcie: add BCM2838 PCIe Root Complex Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 02/19] hw/arm/bcm2838_pcie: add BCM2838 PCIe host Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 03/19] hw/arm/bcm2838: enable BCM2838 PCIe host bridge Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 04/19] hw/net/bcm2838_genet: add GENET stub device Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 05/19] hw/net/bcm2838_genet: add GENET register structs, part 1/4 Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 06/19] hw/net/bcm2838_genet: add GENET register structs, part 2/4 Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 07/19] hw/net/bcm2838_genet: add GENET register structs, part 3/4 Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 08/19] hw/net/bcm2838_genet: add GENET register structs, part 4/4 Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 09/19] hw/net/bcm2838_genet: add GENET register access macros Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 10/19] hw/net/bcm2838_genet: implement GENET register ops Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 11/19] hw/net/bcm2838_genet: implement GENET MDIO Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 12/19] hw/net/bcm2838_genet: implement GENET TX path Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 13/19] hw/net/bcm2838_genet: implement GENET RX path Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 14/19] hw/arm/bcm2838: enable BCM2838 GENET controller Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 15/19] hw/net/bcm2838_genet: fix PHY autonegotiation-restart deadlock Marcelo Manzo
2026-08-11 14:35 ` Marcelo Manzo [this message]
2026-08-11 14:35 ` [PATCH v2 17/19] hw/net/bcm2838_genet: fix TX ring activation check Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 18/19] docs/system/arm/raspi: move PCIe/GENET from missing to implemented Marcelo Manzo
2026-08-11 14:35 ` [PATCH v2 19/19] tests/functional/aarch64: add raspi4b GENET networking test Marcelo Manzo
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=20260811143557.7862-17-marcelomanzo@gmail.com \
--to=marcelomanzo@gmail.com \
--cc=jasowangio@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@mailo.com \
--cc=philmd@oss.qualcomm.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.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