Simon Horman
2009-May-02 02:10 UTC
[Xen-devel] Regression in PCI pass-through from qemu-xen changeset "passthrough: Fix older kernel assigned device resume failure problem"
Changeset "passthrough: Fix older kernel assigned device resume failure problem" (dbb8aafa702b8b4f5568e08641d98471fd04e0f8) in qemu-xen-unstable.git appears to cause a regression. This changeset was applied between the xen-3.4.0-rc2 and xen-3.4.0-rc3 tags of qemu-xen-unstable.git. [ This problem was previously reported as being in the previous changeset, "Fix hvm guest cirrus_vga hvm s3 resume failure". Apologies for any confusion that may cause ] The problem that I am seeing is that with this changeset applied I am not able to correctly initialise Intel network cards. Though I assume the problem is not specific to this hardware. In the case of an Intel e100 82557/8/9/0/1 the problem manifests as the EEPROM being declared invalid, although the device seems to be usable by domU. In the case of an Intel igb 82576 the card is initialised by the guest operating system but is unable to establish a link and ethtool returning invalid values for the supported ports - it tells me the card has fibre when in fact it has copper. domU is running x86_32 2.6.30-rc4. dom0 is x86_64. -- Simon Horman VA Linux Systems Japan K.K. Satellite Lab in Sydney, Australia H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Simon Horman
2009-May-02 02:18 UTC
Re: [Xen-devel] Regression in PCI pass-through from qemu-xen changeset "passthrough: Fix older kernel assigned device resume failure problem"
[ Added Shimada-san to CC list ] On Sat, May 02, 2009 at 12:10:15PM +1000, Simon Horman wrote:> Changeset "passthrough: Fix older kernel assigned device resume failure > problem" (dbb8aafa702b8b4f5568e08641d98471fd04e0f8) in > qemu-xen-unstable.git appears to cause a regression. This changeset was > applied between the xen-3.4.0-rc2 and xen-3.4.0-rc3 tags of > qemu-xen-unstable.git. > > [ This problem was previously reported as being in the previous > changeset, "Fix hvm guest cirrus_vga hvm s3 resume failure". > Apologies for any confusion that may cause ] > > The problem that I am seeing is that with this changeset applied > I am not able to correctly initialise Intel network cards. Though > I assume the problem is not specific to this hardware. > > In the case of an Intel e100 82557/8/9/0/1 the problem manifests as the > EEPROM being declared invalid, although the device seems to be usable > by domU. > > In the case of an Intel igb 82576 the card is initialised by the > guest operating system but is unable to establish a link and > ethtool returning invalid values for the supported ports - > it tells me the card has fibre when in fact it has copper. > > domU is running x86_32 2.6.30-rc4. dom0 is x86_64.-- Simon Horman VA Linux Systems Japan K.K. Satellite Lab in Sydney, Australia H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2009-May-05 13:58 UTC
Re: [Xen-devel] Regression in PCI pass-through from qemu-xen changeset "passthrough: Fix older kernel assigned device resume failure problem"
Simon Horman writes ("Re: [Xen-devel] Regression in PCI pass-through from
qemu-xen changeset "passthrough: Fix older kernel assigned device resume
failure problem""):
On Sat, May 02, 2009 at 12:10:15PM +1000, Simon Horman
wrote:> Changeset "passthrough: Fix older kernel assigned device resume
failure
> problem" (dbb8aafa702b8b4f5568e08641d98471fd04e0f8) in
> qemu-xen-unstable.git appears to cause a regression. This changeset was
> applied between the xen-3.4.0-rc2 and xen-3.4.0-rc3 tags of
> qemu-xen-unstable.git.
...> The problem that I am seeing is that with this changeset applied
> I am not able to correctly initialise Intel network cards. Though
> I assume the problem is not specific to this hardware.
Thanks ...
Cui, Dexuan writes ("[PATCH][ioemu] fix PCI bar
mapping"):> dbb8aafa702b8b4f5568e08641d98471fd04e0f8 has a bug:
> The virtual CMD value we get from reg_entry->data is not the proper
value because reg_entry->data only holds the emulated bits and the
PCI_COMMAND_IO/PCI_COMMAND_MEMORY bits are not in it.
> Instead, we can use pt_pci_read_config(&ptdev->dev, PCI_COMMAND, 2)
to get the proper value.
... Cui, do you think this is likely to fix Simon''s problem ?
I''m about to apply it, in any case, but I was wondering if we have
another problem too.
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Cui, Dexuan
2009-May-05 16:23 UTC
RE: [Xen-devel] Regression in PCI pass-through from qemu-xen changeset "passthrough: Fix older kernel assigned device resume failure problem"
Ian Jackson wrote:> Simon Horman writes ("Re: [Xen-devel] Regression in PCI pass-through > from qemu-xen changeset "passthrough: Fix older kernel assigned > device resume failure problem""): On Sat, May 02, 2009 at 12:10:15PM > +1000, Simon Horman wrote: >> Changeset "passthrough: Fix older kernel assigned device resume >> failure >> problem" (dbb8aafa702b8b4f5568e08641d98471fd04e0f8) in >> qemu-xen-unstable.git appears to cause a regression. This changeset >> was >> applied between the xen-3.4.0-rc2 and xen-3.4.0-rc3 tags of >> qemu-xen-unstable.git. > ... >> The problem that I am seeing is that with this changeset applied >> I am not able to correctly initialise Intel network cards. Though >> I assume the problem is not specific to this hardware. > > Thanks ... > > Cui, Dexuan writes ("[PATCH][ioemu] fix PCI bar mapping"): >> dbb8aafa702b8b4f5568e08641d98471fd04e0f8 has a bug: >> The virtual CMD value we get from reg_entry->data is not the proper >> value because reg_entry->data only holds the emulated bits and the >> PCI_COMMAND_IO/PCI_COMMAND_MEMORY bits are not in it. Instead, we >> can use pt_pci_read_config(&ptdev->dev, PCI_COMMAND, 2) to get the >> proper value. > > ... Cui, do you think this is likely to fix Simon''s problem ?Yes, I think this should fix Simon''s problem since actually I meet with the same symptom and I made the patch to fix it.> > I''m about to apply it, in any case, but I was wondering if we have > another problem too.I don''t see another problem. Yes, please apply it. Thanks! Thanks, -- Dexuan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Simon Horman
2009-May-05 23:17 UTC
Re: [Xen-devel] Regression in PCI pass-through from qemu-xen changeset "passthrough: Fix older kernel assigned device resume failure problem"
On Wed, May 06, 2009 at 12:23:27AM +0800, Cui, Dexuan wrote:> Ian Jackson wrote: > > Simon Horman writes ("Re: [Xen-devel] Regression in PCI pass-through > > from qemu-xen changeset "passthrough: Fix older kernel assigned > > device resume failure problem""): On Sat, May 02, 2009 at 12:10:15PM > > +1000, Simon Horman wrote: > >> Changeset "passthrough: Fix older kernel assigned device resume > >> failure > >> problem" (dbb8aafa702b8b4f5568e08641d98471fd04e0f8) in > >> qemu-xen-unstable.git appears to cause a regression. This changeset > >> was > >> applied between the xen-3.4.0-rc2 and xen-3.4.0-rc3 tags of > >> qemu-xen-unstable.git. > > ... > >> The problem that I am seeing is that with this changeset applied > >> I am not able to correctly initialise Intel network cards. Though > >> I assume the problem is not specific to this hardware. > > > > Thanks ... > > > > Cui, Dexuan writes ("[PATCH][ioemu] fix PCI bar mapping"): > >> dbb8aafa702b8b4f5568e08641d98471fd04e0f8 has a bug: > >> The virtual CMD value we get from reg_entry->data is not the proper > >> value because reg_entry->data only holds the emulated bits and the > >> PCI_COMMAND_IO/PCI_COMMAND_MEMORY bits are not in it. Instead, we > >> can use pt_pci_read_config(&ptdev->dev, PCI_COMMAND, 2) to get the > >> proper value. > > > > ... Cui, do you think this is likely to fix Simon''s problem ? > Yes, I think this should fix Simon''s problem since actually I meet with the same symptom and I made the patch to fix it.Hi, I did some testing this morning and Dexuan''s patch appears to solve the problem that I was seeing. Thanks -- Simon Horman VA Linux Systems Japan K.K. Satellite Lab in Sydney, Australia H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Cui, Dexuan
2009-May-05 23:45 UTC
RE: [Xen-devel] Regression in PCI pass-through from qemu-xen changeset "passthrough: Fix older kernel assigned device resume failure problem"
Simon, thanks a lot for the testing! BTW, the patch has been checked into staging ioemu-remote tree(http://xenbits.xensource.com/git-http/staging/qemu-xen-unstable.git). Thanks, -- Dexuan -----Original Message----- From: Simon Horman [mailto:horms@verge.net.au] Sent: 2009年5月6日 7:18 To: Cui, Dexuan Cc: Ian Jackson; xen-devel@lists.xensource.com; Zhao, Yu; Keir Fraser; Ke, Liping; Yuji Shimada Subject: Re: [Xen-devel] Regression in PCI pass-through from qemu-xen changeset "passthrough: Fix older kernel assigned device resume failure problem" On Wed, May 06, 2009 at 12:23:27AM +0800, Cui, Dexuan wrote:> Ian Jackson wrote: > > Simon Horman writes ("Re: [Xen-devel] Regression in PCI pass-through > > from qemu-xen changeset "passthrough: Fix older kernel assigned > > device resume failure problem""): On Sat, May 02, 2009 at 12:10:15PM > > +1000, Simon Horman wrote: > >> Changeset "passthrough: Fix older kernel assigned device resume > >> failure > >> problem" (dbb8aafa702b8b4f5568e08641d98471fd04e0f8) in > >> qemu-xen-unstable.git appears to cause a regression. This changeset > >> was > >> applied between the xen-3.4.0-rc2 and xen-3.4.0-rc3 tags of > >> qemu-xen-unstable.git. > > ... > >> The problem that I am seeing is that with this changeset applied > >> I am not able to correctly initialise Intel network cards. Though > >> I assume the problem is not specific to this hardware. > > > > Thanks ... > > > > Cui, Dexuan writes ("[PATCH][ioemu] fix PCI bar mapping"): > >> dbb8aafa702b8b4f5568e08641d98471fd04e0f8 has a bug: > >> The virtual CMD value we get from reg_entry->data is not the proper > >> value because reg_entry->data only holds the emulated bits and the > >> PCI_COMMAND_IO/PCI_COMMAND_MEMORY bits are not in it. Instead, we > >> can use pt_pci_read_config(&ptdev->dev, PCI_COMMAND, 2) to get the > >> proper value. > > > > ... Cui, do you think this is likely to fix Simon''s problem ? > Yes, I think this should fix Simon''s problem since actually I meet with the same symptom and I made the patch to fix it.Hi, I did some testing this morning and Dexuan''s patch appears to solve the problem that I was seeing. Thanks -- Simon Horman VA Linux Systems Japan K.K. Satellite Lab in Sydney, Australia H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Simon Horman
2009-May-06 00:21 UTC
Re: [Xen-devel] Regression in PCI pass-through from qemu-xen changeset "passthrough: Fix older kernel assigned device resume failure problem"
On Wed, May 06, 2009 at 07:45:51AM +0800, Cui, Dexuan wrote:> Simon, thanks a lot for the testing! > BTW, the patch has been checked into staging ioemu-remote tree(http://xenbits.xensource.com/git-http/staging/qemu-xen-unstable.git).Thanks, I have also confirmed that the staging tree is working for me. -- Simon Horman VA Linux Systems Japan K.K. Satellite Lab in Sydney, Australia H: www.vergenet.net/~horms/ W: www.valinux.co.jp/en _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel