When viona creates a new link atop a mac provider, it is created with link->l_promisc = VIONA_PROMISC_MULTI; set so that guests which do not support the VIRTIO_NET_F_CTRL_RX capability can receive multicast traffic implicitly. viona expects that for compatible guests, the VMM will alter this via the VNA_IOC_SET_PROMISC ioctl as required. Propolis doesn't support this capability or unset promiscuous mode today; this results in the device doing some extra unnecessary work for every unicast packet on the receive side to verify that it is, in fact, a unicast packet.
There are some complications in advertising VIRTIO_NET_F_CTRL_RX. This feature covers two main pieces; the guest is allowed to explicitly request promiscuous mode (or all-multicast mode), but it can also push down arbitrary unicast/multicast filters in addition to its primary MAC. Viona itself doesn't have any plumbing to perform this filtering (or push it down to MAC, the VNIC, the NIC...). It's probably reasonable as a first pass that we treat the presence of a unicast/multicast filter table as just cause to move into one of the promiscuous modes, and the spec does suggest that devices are free to do this.
This capability does not require that we allow guests to alter their actual MAC address via the VIRTIO_NET_F_CTRL_MAC_ADDR capability. We might make that a toggleable feature of the interface, since OPTE relies quite heavily on guests sticking with the MAC address we give them. Technically a transitional/legacy driver is allowed to write straight into NetReg::Mac without this flag, but we ignore any writes to the config struct regardless.
When
vionacreates a new link atop a mac provider, it is created withlink->l_promisc = VIONA_PROMISC_MULTI;set so that guests which do not support theVIRTIO_NET_F_CTRL_RXcapability can receive multicast traffic implicitly.vionaexpects that for compatible guests, the VMM will alter this via theVNA_IOC_SET_PROMISCioctl as required. Propolis doesn't support this capability or unset promiscuous mode today; this results in the device doing some extra unnecessary work for every unicast packet on the receive side to verify that it is, in fact, a unicast packet.There are some complications in advertising
VIRTIO_NET_F_CTRL_RX. This feature covers two main pieces; the guest is allowed to explicitly request promiscuous mode (or all-multicast mode), but it can also push down arbitrary unicast/multicast filters in addition to its primary MAC. Viona itself doesn't have any plumbing to perform this filtering (or push it down to MAC, the VNIC, the NIC...). It's probably reasonable as a first pass that we treat the presence of a unicast/multicast filter table as just cause to move into one of the promiscuous modes, and the spec does suggest that devices are free to do this.This capability does not require that we allow guests to alter their actual MAC address via the
VIRTIO_NET_F_CTRL_MAC_ADDRcapability. We might make that a toggleable feature of the interface, since OPTE relies quite heavily on guests sticking with the MAC address we give them. Technically a transitional/legacy driver is allowed to write straight intoNetReg::Macwithout this flag, but we ignore any writes to the configstructregardless.