feat(virtio): support multicast

[Enigamict]

Description

The main multicast implementation was inherited from that pull request and I’m committing it as Co-authored.
#592

For CTRL_VQ, Awkernel currently accepts every packet. This causes issues such as

https://github.com/tier4/awkernel/blob/main/awkernel_drivers/src/pcie/virtio/virtio_net.rs#L1113

[ 1441 ERROR] kernel/src/nostd.rs:162: panic: panicked at awkernel_drivers/src/pcie/virtio/virtio_net.rs:485:18:
called Result::unwrap() on an Err value: EtherFrameBuf { data: […], vlan: None }
… stack trace …
[ 1511 ERROR] kernel/src/nostd.rs:162: panic: panicked at .../session_types.rs:188:9:
Session channel prematurely dropped

Because, CTRL_VQ is unimplemented we fall back to ALLMULTI | PROMISC
So multicast traffic(mDNS)that we never joined also enters the RX ring. The upper session_types layer assumes “only frames I should process will arrive” and blindly unwraps, so unexpected frames surface as Err(EtherFrameBuf) and crash.

https://github.com/tier4/awkernel/blob/main/awkernel_drivers/src/pcie/virtio/virtio_net.rs#L481

This issue. We know this crash is triggered by the burst of mDNS packets emitted when a tap or bridge is created and brought UP for the first time. I haven’t yet found a good reference for addressing this, so I’ll keep the issue open until we can implement it.

Related links

How was this PR tested?

Notes for reviewers

[Enigamict]

This PR is intentionally limited to improving RX burst tolerance rather than proving the correctness of vio_iff() or CTRL_VQ-based filtering. The immediate crash we are seeing is caused by software RX queue overflow during early traffic bursts, where rx_buffer.push(...).unwrap() panics when the queue is full

awkernel/awkernel_drivers/src/pcie/virtio/virtio_net.rs

Line 479 in 0912ef8

self.rx_buffer

To address that direct failure path, this change increases RECV_QUEUE_SIZE and replaces the unwrap() with explicit queue-full handling that drops the frame and logs the event.