on the plus side, with the 'malicious' driver notifications in e810, it is a bit easier to figure out when things have gone wrong :)

Malicious driver notifications?

So, someone with a Boston driver?

er, a Boston driver. (so much for editing)

since the NIC allows virtualizing itself and presenting a subset of its resources to a VM, it has notifications if bad data is passed to it

the name i think is likely misleading as it's more likely to be just a bug than malicious intent from a VM (obviously possible, but on the range of probabilities)

[illumos-gate] 18317 libzfs mnttab cache aborts on duplicate mnttab entries -- Brian Behlendorf <behlendorf1⊙lg>

[illumos-gate] 18272 vioif: add multi-queue (VIRTIO_NET_F_MQ) support -- Andy Fiddaman <illumos⊙fn>

Yeah, those existed in the 700 series too. Ultimately we should never get one of those from the hardware otherwise something has gone really wrong.

yeah, i added a bit to print out the specific errors, since that did help spot a few bugs

my kingdom to be able to get more than an hour at a time to focus :)

boy when it rains... so a full adminq error on an i40e nic...

[illumos-gate] 18363 cxgbetool cudbg --collect rss panics host -- Ryan Zezeski <ryan⊙zc>

[illumos-gate] 18304 add ddi_ncpus_expected(9F) for sizing per-CPU resources -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 18358 virtio_map_cap() reuses another device's BAR register number -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 18361 vioif accepts offload features whose dependencies are missing -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 18360 vioif reports a nonsense MAC_PROP_SPEED when the device speed is unknown -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 18359 virtio: virtio_queue_alloc() can return with vio_mutex held -- Andy Fiddaman <illumos⊙fn>