Commandeering this revision, since I've taken over with new patches.

• Fix cut-n-pasto
• Add a check that no invalid prot flags have been passed.

Update patch to latest tree.

In D20609#445839, @v.maffione_gmail.com wrote:

Do you mean a common vq_notify callback for both transmit and receive queue? But pci_vtnet_ping_txq() and pci_vtnet_ping_rxq() perform different work ...

The point here is that the virtio-net frontend does not support (yet) receive backpressure towards the backend. This means that if the backend receives packets faster than the guest can consume them,
packets are dropped (see https://svnweb.freebsd.org/base/head/usr.sbin/bhyve/pci_virtio_net.c?view=markup#l311), wasting CPU cycles. Adding backpressure would mean to disable the backend packet receive until the guest is ready to receive more.
Because receive backpressure is missing, receive kicks are kept always disabled. On device reset, kicks are actually enabled. When the first receive kick comes (pci_vtnet_ping_rxq), kicks are disabled (vq_kick_disable), and never enabled again. This explains why that pci_vtnet_ping_rxq is called only once for each reset.
Another consequence of the missing receive backpressure is that receive operation in the backend is enabled while the reset is in progress. In other words, pci_vtnet_tap_rx() can be called while the reset is in progress, and that's why we need the vsc_rx_ready variable. If we had receive backpressure, one could just disable backend receive operation while the reset is in progress.

I plan to implement receive backpressure (plus other stuff), but more preparatory patches are needed before getting to that point.

In D20673#446746, @cem wrote:

As a first-cut workaround, LGTM.

Longer term, I don't like that there's no real synchronization between the two threads. Also I think this could pretty easily be converted to a single thread, obviating the need for synchronization.

In D18880#446473, @emaste wrote:

*** Check failed: /root/freebsd/tests/sys/vm/mmap_test.c:107: MAP_ANON with extra PROT flags succeeded
*** Check failed: /root/freebsd/tests/sys/vm/mmap_test.c:107: shm fd with garbage PROT succeeded

I'll start on updating the tests for this change, but as it is initially disabled by default (after correcting the copy-pasteo, at least) IMO it can go in now.

The "trimonce" option should be documented in the fstab(5) man page, share/man/man5/fstab.5, and the -E option should be documented in the swapon(8) man page, sbin/swapon/swapon.8.

As a first-cut workaround, LGTM.

OK from manpages. Thanks!

Perfect! Thanks!

Thanks!

As per comment from madpilot, manually strip the patch from upstream,
rather than getting the ports framework to do it

• - missed rename of variable

• fix comment to be in-line with RFC

This looks straightforward. Approved.

It is definitely a standard option. The patch would solve the Q/A problem.

I tested successfully the patch for www/firefox.

I have a kind-of stupid question: where in all this do you actually walk an entire header chain to the end rather than just checking the next one? Are there no cases when this might be needed?

In D20636#446616, @alc wrote:

I would suggest that you add a comment to the code explaining why the callout is necessary.

Looks OK to me. One possible nit