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

[Martin Harvey <martin.harvey@xxxxxxxxxx>]

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. 

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.

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?

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