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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----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
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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).

> 
> 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%28v=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.

> 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?

  Paul

> 
> - --
> RafaÅ WojdyÅa
> Qubes Tools for Windows developer
> -----BEGIN PGP SIGNATURE-----
> 
> iQEcBAEBAgAGBQJVXFwyAAoJEIWi9rB2GrW7zv8H/jyexqUlL7qTq7z++s/pHcC
> u
> bo1Gz6IeY1T0fJto4UcQH1Qs8JZ9SVpiP94UT9BorJCvll1FRSSFpyXP3aHtkOKP
> P8aCktaZ7EuUL6wy7WryIYtHD9tG46xYe1N0lqKoQASZZH97qWaNrl/4B06/nvY
> x
> 32yS3sqEwMzAKpDit17KcslZM9LES55IhWGggLag+tvPBKCdNHIG6sqebnFbfySl
> 6Xh5qoSTqWzbDU2pejKklmpxIONSzUxXMxLckScn1TjY8PGmEpjF1LpmVCc+f
> 0cz
> YKpuHBruStcmELvZO5t+Yg9RN89sX3EAtuJVfEaBOewq+Q5Om6ToY/k0Y+FGG
> CA=
> =MIh4
> -----END PGP SIGNATURE-----
_______________________________________________
win-pv-devel mailing list
win-pv-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/win-pv-devel