This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-users] GPLPV on NetBSD dom0

To: xen-users <xen-users@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-users] GPLPV on NetBSD dom0
From: Dustin Marquess <dmarquess@xxxxxxxxx>
Date: Tue, 8 Jun 2010 15:16:14 -0500
Cc: James Harper <james.harper@xxxxxxxxxxxxxxxx>
Delivery-date: Tue, 08 Jun 2010 13:19:14 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=P6rsMzHCS6ibrIqONfFt1Gi5g5NFajS1aNIExF0qPfM=; b=p3CeXmQrCRee07DatJOA42OGYTFIfqcqm0ouuEozs9lD1XyXhts8gw+9KiIZt/Qz87 AhEC0BbnQGFOzMWNGeOUx2MlOVMXwg8ICIEOgIzPmRaqFXOQ2WubAOvDteNsC4RrH/iq xCBD4JNONhSMv68jor9ueGA0dsnaQT0e8aXrM=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=rpy4lx3ou8S3yars1M+5gYqElEY+Mbw5qwlKpdMsVBxu1GD/d/+q+6wK1q43ftLT/F n5qSMtaghTghNmmdL969AuE2kFRTfRT9qtOXOmCqGpcYaARwb4LjZKDql5IMl8k48PCo UWEH7QUZt9T3u9mAt13VD7REbbISLK1DQezQM=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
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
<Prev in Thread] Current Thread [Next in Thread>