Finally got a chance to look at this again.|
Trying to install GPLPV on a Windows domU while running under a NetBSD/dom0 (Xen 3.3.2) causes a STOP 0x0000007B at boot. Going through the debug output a few months ago, James thought it had to do with the backend state.
Looking at the code, XenPci_XenConfigDeviceSpecifyBuffers() calls XenPci_ChangeFrontendState() with a backend_state_response of XenbusStateInitWait, however the current backend state is XenbusStateConnected. Because of this it eventually times out, fails, and then Windows can't find the drive and STOPs.
As a quick kludge, in XenPci_ChangeFrontendState() before the while() loop I added:
if ((backend_state_response == XenbusStateInitWait)&&(xppdd->backend_state == XenbusStateConnected))
backend_state_response = XenbusStateConnected;
After recompiling the drivers and loading them, everything appears to work fine.
So my question is, is this a NetBSD bug (bringing the devices up to the the wrong state too early), or it is a GPLPV bug? I tried comparing the NetBSD Xen kernel code against the code in the Linux kernel and I didn't see anything that stood out. If it's a NetBSD problem, I'll open a PR in their bug system.
Xen-users mailing list