From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50108) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TP9Ml-00084W-57 for qemu-devel@nongnu.org; Fri, 19 Oct 2012 05:59:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TP9Mi-0002S0-4L for qemu-devel@nongnu.org; Fri, 19 Oct 2012 05:59:43 -0400 Received: from mail.univention.de ([82.198.197.8]:2260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TP9Mh-0002Rq-R7 for qemu-devel@nongnu.org; Fri, 19 Oct 2012 05:59:40 -0400 From: Philipp Hahn Date: Fri, 19 Oct 2012 11:59:24 +0200 References: <1316635586-4586-1-git-send-email-dann.frazier@canonical.com> In-Reply-To: <1316635586-4586-1-git-send-email-dann.frazier@canonical.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1742151.N9YxLhzfAf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201210191159.29855.hahn@univention.de> Subject: Re: [Qemu-devel] [PATCH] e1000: Don't set the Capabilities List bit List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, Anthony Liguori Cc: dann frazier --nextPart1742151.N9YxLhzfAf Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, On Wednesday 21 September 2011 22:06:25 dann frazier wrote: > The Capabilities Pointer is NULL, so this bit shouldn't be set. The state > of this bit doesn't appear to change any behavior on Linux/Windows versio= ns > we've tested, but it does cause Windows' PCI/PCI Express Compliance Test = to > balk. =2E.. > +++ b/hw/e1000.c > @@ -1151,8 +1151,6 @@ static int pci_e1000_init(PCIDevice *pci_dev) =2E.. > - /* TODO: we have no capabilities, so why is this bit set? */ > - pci_set_word(pci_conf + PCI_STATUS, PCI_STATUS_CAP_LIST); I think that change introduced a upgrade problem: We have several VMs initially setup with qemu-0.12 and 0.14. Over the time = of=20 years we've created lots of snapshots, which we'd like to keep. Now it's time to upgrade qemu(-kvm) on our hosts to qemu-1.1.2, but trying = to=20 load the old save states failes with qemu: warning: error while loading state for instance 0x0 of=20 device '0000:00:03.0/e1000' I traced it down to get_pci_config_device() failung for the e1000, because = of=20 that changed bit: (gdb) print /x config@256=20 $23 =3D {0x86, 0x80, 0xe, 0x10, 0x7, 0x0, 0x18, 0x0, 0x3, 0x0, 0x0, 0x2, 0x= 0,=20 0x0, 0x0, 0x0, 0x0, 0x0, 0x2, 0xf2, 0x41, 0xc0, 0x0 , 0xf= 4,=20 0x1a, 0x0, 0x11, 0x0, 0x0, 0x4, 0xf2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,=20 0x0, 0xb, 0x1, 0x0 } (gdb) print /x *s->config@256=20 $25 =3D {0x86, 0x80, 0xe, 0x10, 0x0, 0x0, 0x0, 0x0, 0x3, 0x0, 0x0, 0x2, 0x0= ,=20 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1, 0x0 , 0xf4, 0x1a,= =20 0x0, 0x11, 0x0 , 0x1, 0x0 } Since cmask[PCI_STATUS=3D6] =3D PCI_STATUS_CAP_LIST=3D0x10 marks that bit a= s=20 unmodifiable, the functions returns an error and aborts loading the saved=20 state. Is this problem known? Is such an upgrade of qemu supposed to work? Has somebody an idea how to fix this issue? Sincerely Philipp Hahn PS: It would be nice if the error message could indicate an error because o= f=20 an incompatible PCI configuration. I had a very similar problem with the=20 rtl8139 card, where the ROM size was changed due to the upgrade from=20 etherboot to iPXE. PPS: It's slightly confusing to get a 'warning' message starting with 'erro= r=20 loading ...' =2D-=20 Philipp Hahn Open Source Software Engineer hahn@univention.de Univention GmbH be open. fon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ --nextPart1742151.N9YxLhzfAf Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAlCBJH0ACgkQYPlgoZpUDjm8ogCdFR0xBhWljj+HKBPAyzW2VQVg WooAoLeTCPt3TBjzTe1QX9l3lEthIJwV =T17M -----END PGP SIGNATURE----- --nextPart1742151.N9YxLhzfAf--