bhyve: e82545: drop frames that are too long for the guest

[wanpengqian_gmail.com]

Summary

Unless the guest sets RCTL.LPE, the 8254x discards frames longer than
1522 bytes. The device model used that limit only to work out how many
descriptors a frame can take: a longer frame that fitted the buffers,
up to 2048 bytes with the usual buffer size, was handed to the guest.

A bridge with LRO enabled on a member delivered 1634-byte frames to
the tap interface. Linux's e1000 driver panicked in skb_put() and
Windows' driver stopped receiving.

Drop such frames as the hardware does.

Signed-off-by: Wanpeng Qian <[e-mail]>
Sponsored by: keelos.dev

Test Plan

main (f958aa7e7), FreeBSD 16.0-CURRENT guest with -s 3,e1000,tap0, em0 with the default MTU of 1500 (RCTL.LPE clear). On the host the MTU of tap0 was raised to 9000 and frames of several sizes were sent with ping -D -s SIZE (3 pings each):

frame	before	after
1514 bytes (-s 1472)	3 replies	3 replies
1518 bytes (-s 1476)	3 replies	3 replies
1518 bytes with a VLAN tag (-s 1472 on a vlan(4))		3 replies
1519 bytes (-s 1477)	3 replies	none
1642 bytes (-s 1600)	3 replies	none
2042 bytes (-s 2000)	3 replies	none
1514 bytes again	3 replies	3 replies

1518 bytes without the CRC is the 1522-byte limit of the hardware.

How it was found (FreeBSD 14.5): guests on a bridge whose physical member is a vlan(4) on an igb(4) port with LRO left on. The bridge handed 1634-byte frames to the tap interfaces. A Linux guest's e1000 driver panicked in skb_put(), a Windows 10 guest's stopped receiving. With this change the Linux guest no longer panics (the transfer stalls until LRO is turned off, as it would with a real 8254x).