Re: [win-pv-devel] XENIFACE not attaching to XENBUS

[RafaÅ WojdyÅa <omeg@xxxxxxxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2015-05-20 16:15, Paul Durrant wrote:
>> -----Original Message----- From: 
>> win-pv-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:win-pv-devel- 
>> bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Rafal Wojdyla Sent:
>> 20 May 2015 11:05 To: win-pv-devel@xxxxxxxxxxxxxxxxxxxx Subject:
>>  [win-pv-devel] XENIFACE not attaching to XENBUS
>> 
> Hello,
> 
> I've noticed something strange when I was experimenting with
> adding new APIs to Xenbus. I added a Store API to set key
> permissions and incremented the store interface version as usual
> (to 2 from 1).
> 
>> Presumably you created a new interface version, left the old one
>> as version 1, called the new one 2, and then bumped the max
>> version to 2? It looks like that's what you did.
> 
> Everything seemed fine, the driver installed normally. I rebuilt 
> Xeniface with the new header and proceeded to install it on the
> test system. The install went fine as well. However, after a reboot
> the Xeniface driver wasn't being loaded. Or, to be more precise, it
> got loaded and then immediately unloaded by PnP for some reason. I
>  haven't changed INFs or anything except the store interface header
>  and the .c file.
> 
>> Well, the lack of change in the xeniface INF is a problem. It's
>> a bit hacky but, each combination of interface versions exported
>> by a driver correspond to a unique revision number for PDOs
>> created by that driver, so by bumping the max version of the
>> store interface a whole new set of xenbus PDO revisions are
>> available. Any client driver must bind to the PDO revision
>> corresponding to the set of interface versions which it plans to
>> use. This is so that, should an old version of any interface be
>> retired, all corresponding PDO revisions will disappear and thus
>> any old client driver will no longer bind (causing Windows to go
>> and look for something new on Windows Update - where Citrix hope
>> to eventually have drivers available).

I see - so the best course is to bind to a specific revision.

> 
> When I moved my new function to the v1 interface and removed the v2
>  everything went back to normal. That's not a solution of course,
> just wanted to test what would happen. I'm not sure what's going
> on, is there some limit to the number of revisions? With many
> different interface versions the revision count seems to be going
> up very quickly...
> 
> 
>> However, since you did not modify the inf, xeniface should still
>> be binding to revision 1 of the PDO and your log shows that is
>> still being created. The doc at 
>> https://msdn.microsoft.com/en-us/library/windows/hardware/ff539950%28
v=vs.85%29.aspx
>>
>>
>>
>>
>>
>> 
says that the maximum number is 64 and there are only 0x28 (40) in
>> the list so the old compatible ID should still be there. You
>> should be able to check via device manager to make sure though.

That's what got me confused because the xeniface driver *was* binding
to xenbus without an INF change before, but not now. I'll check how
the revision list looks in the device details.

> 
> I've attached a debug log from test system boot that shows xeniface
>  being loaded and unloaded.
> 
>> Perhaps the fact that the binding went from the actual hardware
>> id to a compatible id is a problem... maybe Windows doesn't like
>> that even though the driver should still bind. After Windows has
>>  unloaded xeniface, what happens if you right click on the device
>> in device manager and do a 'Update Driver Software'? Does it
>> reload, or does Windows genuinely believe the driver is not
>> compatible?

I've tried that - Windows thinks it's incompatible (probably) and the
driver doesn't load. When trying to install through dpinst it just
skips to the end showing that the driver is installed with the green
check mark. I did see xeniface's key in the registry but as said, it's
not being loaded.

> 
>> Paul
> 

- -- 
RafaÅ WojdyÅa
Qubes Tools for Windows developer
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJVXNgQAAoJEIWi9rB2GrW7pqoH/1n4PcCCpMRm9SBOJ5Ax0lmy
dj3ND5YcKmeZK/OIQSpHAqHfjEg7esk9lpeO8M2iSV/6isbhfLA9vSc8y8kvTMEe
UF7+7iaAoeBrOJvSGyiz/sPqx+kxq/tkVeC0vXGxxRqXZWQMDPn0ZnWYr6jNVRA7
2RG96aBTrF23aOR80r3igqLCSYN0rmalwrW/VFcoRitBl4Djs9TUTdk4gY41cRf4
HxPlYja38sJfwFr8EX1H+P7L3+2oK7u6EuJvd+TBfNcL3lsXFmCyKD8dlqgGPuZ6
U8IAVmq8e3VYjq/NQUSq2zjYvf6ftQxnm912PhCzhiZr1KJfk4TXsnI6ordBInM=
=g+s9
-----END PGP SIGNATURE-----

_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel