MFC 321762

    hyperv: Add VF bringup scripts and devd rules.

    How network VF works with hn(4) on Hyper-V in non-transparent mode:

    - Each network VF has a cooresponding hn(4).
    - The network VF and the it's cooresponding hn(4) have the same hardware
      address.
    - Once the network VF is up, e.g. ifconfig VF up:
      o  All of the transmission should go through the network VF.
      o  Most of the reception goes through the network VF.
      o  Small amount of reception may go through the cooresponding hn(4).
         This reception will happen, even if the the cooresponding hn(4) is
         down.  The cooresponding hn(4) will change the reception interface
         to the network VF, so that network layer and application layer will
         be tricked into thinking that these packets were received by the
         network VF.
      o  The cooresponding hn(4) pretends the physical link is down.
    - Once the network VF is down or detached:
      o  All of the transmission should go through the cooresponding hn(4).
      o  All of the reception goes through the cooresponding hn(4).
      o  The cooresponding hn(4) fallbacks to the original physical link
         detection logic.

    All these features are mainly used to help live migration, during which
    the network VF will be detached, while the network communication to the
    VM must not be cut off.  In order to reach this level of live migration
    transparency, we use failover mode lagg(4) with the network VF and the
    cooresponding hn(4) attached to it.

    To ease user configuration for both network VF and non-network VF, the
    lagg(4) will be created by the following rules, and the configuration
    of the cooresponding hn(4) will be applied to the lagg(4) automatically.

    Sponsored by:   Microsoft
    Differential Revision:  https://reviews.freebsd.org/D11635

1 files changed, 73 insertions, 0 deletions

diff --git a/etc/devd/hyperv.conf b/etc/devd/hyperv.conf
index 0abf284..10a4e2b 100644
--- a/etc/devd/hyperv.conf
+++ b/etc/devd/hyperv.conf
@@ -33,3 +33,76 @@ notify 11 {
 	match "cdev"		"hv_fsvss_dev";
 	action "pkill -x hv_vss_daemon";
 };
+
+#
+# Rules for non-transparent network VF.
+#
+# How network VF works with hn(4) on Hyper-V in non-transparent mode:
+#
+# - Each network VF has a cooresponding hn(4).
+# - The network VF and the it's cooresponding hn(4) have the same hardware
+#   address.
+# - Once the network VF is up, e.g. ifconfig VF up:
+#   o  All of the transmission should go through the network VF.
+#   o  Most of the reception goes through the network VF.
+#   o  Small amount of reception may go through the cooresponding hn(4).
+#      This reception will happen, even if the the cooresponding hn(4) is
+#      down.  The cooresponding hn(4) will change the reception interface
+#      to the network VF, so that network layer and application layer will
+#      be tricked into thinking that these packets were received by the
+#      network VF.
+#   o  The cooresponding hn(4) pretends the physical link is down.
+# - Once the network VF is down or detached:
+#   o  All of the transmission should go through the cooresponding hn(4).
+#   o  All of the reception goes through the cooresponding hn(4).
+#   o  The cooresponding hn(4) fallbacks to the original physical link
+#      detection logic.
+#
+# All these features are mainly used to help live migration, during which
+# the network VF will be detached, while the network communication to the
+# VM must not be cut off.  In order to reach this level of live migration
+# transparency, we use failover mode lagg(4) with the network VF and the
+# cooresponding hn(4) attached to it.
+#
+# To ease user configuration for both network VF and non-network VF, the
+# lagg(4) will be created by the following rules, and the configuration
+# of the cooresponding hn(4) will be applied to the lagg(4) automatically.
+#
+# NOTE:
+# If live migration is not needed at all, the following rules could be
+# commented out, and the network VF interface could be used exclusively.
+# Most often the cooresponding hn(4) could be completely ignored.
+#
+#
+# Default workflow for the network VF bringup:
+# 1) ETHERNET/IFATTACH -> VF interface up (delayed by rc.conf hyperv_vf_delay
+#    seconds).  This operation will trigger HYPERV_NIC_VF/VF_UP.
+# 2) HYPERV_NIC_VF/VF_UP:
+#    a) Create laggX coresponding to hnX.
+#    b) Add hnX and VF to laggX.
+#    c) Whack all previous network configuration on hnX, including stopping
+#       dhclient.
+#    d) Apply rc.conf ifconfig_hnX to laggX; i.e. including starting dhclient.
+#
+# NOTE:
+# HYPERV_NIC_VF/VF_UP action script could be customized per-interface by
+# adding /usr/libexec/hyperv/hyperv_vfup.hnX script.
+# /usr/libexec/hyperv/hyperv_vfup could be used as the template for the
+# customized per-interface script.
+#
+# NOTE:
+# For transparent network VF, hyperv_vfattach does nothing and
+# HYPERV_NIC_VF/VF_UP will not be triggered at all.
+#
+
+notify 10 {
+	match "system"		"HYPERV_NIC_VF";
+	match "type"		"VF_UP";
+	action "/usr/libexec/hyperv/hyperv_vfup $subsystem";
+};
+
+notify 10 {
+	match "system"		"ETHERNET";
+	match "type"		"IFATTACH";
+	action "/usr/libexec/hyperv/hyperv_vfattach $subsystem 0";
+};