Re: [win-pv-devel] Two patches to ease upgrade from older drivers.

["Durrant, Paul" <pdurrant@xxxxxxxxxxxx>]

> -----Original Message-----
> From: win-pv-devel <win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of 
> Martin Harvey
> Sent: 04 March 2020 14:46
> To: Durrant, Paul <pdurrant@xxxxxxxxxxxx>; win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: RE: [EXTERNAL][win-pv-devel] Two patches to ease upgrade from older 
> drivers.
> 
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open
> attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> Very well,
> 
> After some discussion it's clear that these are not quite what is required. 
> However, there appears to
> be a slight logical contradiction in the way things work at the moment:
> 
> DEV_VIF Coinstaller has SupportChildDrivers which checks before installing 
> new VIF driver that the
> *existing* (ie *old*) enumerated NET device ID's are supported.... ... 
> despite the fact that it is the
> VIF driver which gets to dictate the device ID's and revision numbers of 
> devices enumerated on the
> bus.

Yes, this is to prevent updating a parent driver in such a way the it becomes 
incompatible with installed children. The correct ordering should be:

1. update parent to one that implements new interface version (but still 
implements older version)
2. update child drivers to use new version
3. update parent again to retire old interface version

It is expected that 1 and 3 are sufficiently far apart chronologically to make 
sure 2 happens. 

> 
> This means that if we remove support for older revisions in the VIF driver, 
> we are also blocking
> automated upgrades, because the co-installer is revision checking in exactly 
> the reverse direction
> from the way upgrades happen.
> 

Well, the intention is that an installer stages new drivers and then allows 
Windows to install in whatever order it chooses. The co-installer thus needs to 
check whether allowing install will break any child that depends upon the 
driver being installed.
So, I guess the problem you have is that you don't have a XENVIF that still 
function with the old XENNET but allow upgrade to the new one. This is not a 
situation which *should* arise when acquiring drivers from Windows Update, but 
which could arise when using an installer. In that case the installer's only 
option is to remove old drivers before installing new ones, and I believe 
that's what the Citrix installer does. Perhaps Ben can comment?

> Surely better to just enumerate newer device id's / revision numbers and then 
> install new NET drivers
> as a result.
> If settings / registry keys need to be copied, then this is probably the 
> responsibility of the new NET
> drivers / new NET co-installer.
> 
> Can you shed any light on how/why this original design decision was made?
> 

Hopefully the explanation above makes sense?

  Paul

> MH.
> 
> -----Original Message-----
> From: Durrant, Paul [mailto:pdurrant@xxxxxxxxxxxx]
> Sent: 03 March 2020 12:40
> To: Martin Harvey <martin.harvey@xxxxxxxxxx>; 
> win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: RE: [win-pv-devel] Two patches to ease upgrade from older drivers.
> 
> De-htmling...
> 
> Responses below:
> 
> -----
> From: win-pv-devel <win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of 
> Martin Harvey
> Sent: 02 March 2020 17:09
> To: win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: [EXTERNAL][win-pv-devel] Two patches to ease upgrade from older 
> drivers.
> 
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open
> attachments unless you can confirm the sender and know the content is safe.
> 
> 
> Submitted for consideration:
> 
> When upgrading from older drivers, installer upgrades can fail, when new NET 
> co-installer refuses to
> recognise older VIF enumerated devices. The subsequent requested reboot 
> leaves the device tree with
> hidden devices with entries still in the MIB table. If these devices are not 
> properly recognised as
> being dormant, they will prevent startup of the new-version NET devices.
> 
> 
> For machines already in this broken state, a suitable workaround is:
> 
> 1. Tried to do the MSI install. Got the failure case, greyed out disabled dev 
> nodes.
> 2.  Remove greyed out devnodes with "uninstall device" (don't delete any 
> drivers).
> 3. On reboot, Xenserver PV Network devices not present: because Xenbus 
> DEV_VIF (one up the device
> tree) is not starting properly.
> 4. Select  "Upgrade Drivers" for DEV_VIF manually, and reboot the machine.
> 5. Upon reboot, machine in working state.
> 
> MH.
> -----
> 
> Please send patches to this list using the same procedures as sending to 
> xen-devel. See
> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches for help with 
> that. (Personally I find
> get send-email the best way). Particularly each patch needs a commit message 
> that adequately justifies
> its existence, so that in many years' time mining the repo will give a clue 
> as to why each change is
> there. (Remember cover letters don't get committed :-))
> 
> The older revisions patch cannot work because VIF interface versions older 
> than 6 are no longer
> implemented, thus it would be unsafe to use it in the presence of an older 
> XENNET (because interface
> acquire would fail) and leave it non-functional, whereas it should be left 
> non-binding thus allowing
> emulated devices to be re-instated. If that is not happening then that's a 
> bug that needs fixing...
> but maybe that's what the other patch does?
> The other patch does not have an adequate commit comment... I guess some of 
> the text here could be
> added to justify it.
> 
>   Cheers,
> 
>     Paul
> 
> _______________________________________________
> win-pv-devel mailing list
> win-pv-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/win-pv-devel
_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/win-pv-devel