Re-work identity stealing code
The change introduced by patch
04c391d9 "Replace copying network
settings with identity stealing" had a flaw...
If a PV device that aliases an emulated device is installed then it
will only steal linkage if that emulated device is operational at the
time. This works on initial driver install, but not if the PV network
device driver is removed and then re-installed without an interim
reboot (which would make the emulated device operational). Instead,
after re-installation, the PV device has a brand new stack binding and
thus any network settings changes that were previously made are
apparently lost.
To fix this problem, this patch breaks the process of stealing the
emulated device's stack binding into two phases:
1) Discovery: When the PV device driver is installed, if an aliasing
emulated device is operational, a DWORD value called "VIF" is
created under the emulated devices software key. The value is set
to the PV device instance.
2) Theft: When the PV device is being brought online, the registry is
checked to see if any network device has a software key containing
a "VIF" value that patches the PV device instance.
If such an entry is found then the stack binding is stolen from
that device. Since the "VIF" value is in the *emulated* device's
software key, it will not be removed if the PV device driver is
removed and re-installed and so the problem described above will
not occur.
Because this patch avoids stealing the emulated device's stack bindings
if it is actually operational (i.e. we're in phase 1) this results in the
class installer building a new set of stack bindings for the PV device
during initial installation.
These are then restored any time a PV device with a stolen stack binding
is offlined. So, when a PV device is offline there is no evidence that
any stack binding has been stolen and hence, during driver removal, there
is no risk of an emulated device's stack binding being torn down.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>