create_instance_v2p_mappings (and its delete counterpart) take an instance and propagate V2P mappings for that instance's NICs to every sled except the instance's current sled. Nexus ignores the current sled because incarnating an instance on a sled (or stopping an incarnation of an instance on a sled) creates (or destroys) XDE ports for that instance's NICs, and the XDE driver creates/destroys the relevant mappings on the local sled when it creates/destroys the port.
This behavior creates some tension for live migration, because Nexus has to worry about being undercut by XDE while applying mappings after a migration completes. The plan to resolve this tension is to have XDE stop manipulating mappings on port creation/deletion (oxidecomputer/opte#368) and let Nexus manage them all instead. Once that change lands and Nexus ingests it, Nexus's V2P mapping routines will need to stop skipping their subject instances' current sleds.
create_instance_v2p_mappings(and itsdeletecounterpart) take an instance and propagate V2P mappings for that instance's NICs to every sled except the instance's current sled. Nexus ignores the current sled because incarnating an instance on a sled (or stopping an incarnation of an instance on a sled) creates (or destroys) XDE ports for that instance's NICs, and the XDE driver creates/destroys the relevant mappings on the local sled when it creates/destroys the port.This behavior creates some tension for live migration, because Nexus has to worry about being undercut by XDE while applying mappings after a migration completes. The plan to resolve this tension is to have XDE stop manipulating mappings on port creation/deletion (oxidecomputer/opte#368) and let Nexus manage them all instead. Once that change lands and Nexus ingests it, Nexus's V2P mapping routines will need to stop skipping their subject instances' current sleds.