In D43047#998921, @cristian.marussi_arm.com wrote:

Thanks for the review @bryanv.
Regarding:

"A virtqueue_poll() variant with a timeout param could be useful in general."

I was thinking exactly the same while doing this, but being a first time contributor to freeBSD, I was not sure how easily acceptable would have been to post a change related to some core system (like virtio) inside this series,
so I went for a custom solution at first. I can certainly post subsequently a patch to add a virtqueue_poll timeout variant to the virtio-core and make use of it in here, once this is merged/landed.

Just a few minor comments. Note though that I only have time to do a brief review of this and haven't read the relevant section of the spec.

Just as a general comment - some of the device_printf() look potentially spammy and may be better as either guarded by bootverbose or debug macros.

I'm very hesitant to consider these - or other virtio methods from other pending reviews - as man "Section 9 - Kernel Interfaces". The header files are not installed and I really don't think should be, and would require clean up before being suitable. Typically these kind methods are not documented in man pages; I think the only existing analogous man(9) would be usbdi(9) and despite the numerous MLINKs only documents a handful of methods around data transfer, that I presume are most relevant for peripheral drivers, and goes into great detail of how those 5 methods are used and related with each other. I think these proposed man pages require a lot more fleshing out before providing the level of detail to code against the "interface".

My intention has been to keep these header files closer aligned with the BSD licensed headers from Linux, which still uses the "vring" prefix. I don't think this change really clarifies much, especially when there are numerous other naming differences between the spec and those upstream header files.

On a very, very quick first glance I've got concerns that this is incomplete, or could break alignment in other cases (but I have been away from this code for awhile). Depending on the features negotiated - V1, legacy with or without mergeable buffers - the header size can vary, along with what we enqueue for the Rx header desc. What features are negotiated on your QEMU testbed? We might be able to get a similar outcome by adjusting VTNET_RX_HEADER_PAD.

Thanks so much for this work! 1-2 years back I think there was an effort to port the full Linux DRM virito_gpu driver over, but I believe that work has stalled. This is great to have.

Address comment

Left a few comments. It has been a long while since I've dealt with vxlan - and FreeBSD network stack in general - so somebody more familiar should give a correctness review.

LGTM