Rose, Gregory V
2009-Oct-22 17:16 UTC
[Xen-devel] Request for backport of 82599 quirks to 3.4.2
Keir, I''d like to request that changset http://xenbits.xensource.com/xen-unstable.hg?rev/091209f1b95c from xen unstable be backported to the 3.4.2 release. Ian, I would also need the changes to pass-through.c in qemu backported. The git commit is a77dc89dde1b8b9331c0f746e34389d6a253755f from Aug. 4. commit a77dc89dde1b8b9331c0f746e34389d6a253755f Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Tue Aug 4 15:28:14 2009 +0100 passthrough: support the assignment of the VF of Intel 82599 10GbE Controlle The datasheet is available at http://download.intel.com/design/network/datashts/82599_datasheet.pdf See ''Table 9.7. VF PCIe Configuration Space'' of the datasheet, the PCI Express Capability Structure of the VF of Intel 82599 10GbE Controller looks trivial, e.g., the PCI Express Capabilities Register is 0, so the Capability Version is 0 and pt_pcie_size_init() would fail. We should not try to expose the PCIe cap of the device to guest. Signed-off-by: Dexuan Cui <dexuan.cui@intel.com> This will allow us and other interested parties to develop and test our 82599 10Gbe adapters on Xen 3.4.2 stable when it becomes available. Thanks, - Greg Rose Lan Access Division (LAD) Intel Corp. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2009-Oct-22 17:35 UTC
[Xen-devel] Re: Request for backport of 82599 quirks to 3.4.2
Rose, Gregory V writes ("Request for backport of 82599 quirks to 3.4.2"):> commit a77dc89dde1b8b9331c0f746e34389d6a253755f > Author: Ian Jackson <ian.jackson@eu.citrix.com> > Date: Tue Aug 4 15:28:14 2009 +0100 > > passthrough: support the assignment of the VF of Intel 82599 10GbE ControlleIf I remember rightly this was a quirk of this particular card. I''d be quite fine with putting that in the 3.4.x branch. Just so we are clear: these two backports both serve the same purpose but as far as I can tell having either of them separately is no worse than having neither ? So there''s no need to coordinate the change across the trees ? Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Rose, Gregory V
2009-Oct-22 17:47 UTC
[Xen-devel] RE: Request for backport of 82599 quirks to 3.4.2
Well they''re both required to pass a VF device through to a guest and then have the VF device properly reset via FLR when the guest is destroyed or shut down. If the qemu quirk to allow pass through of the VF device is committed without the associated quirk in pci.py to go ahead and issue and FLR then there is a possibility that a VF device could be left in some unknown state. It''s a low probability I think but it does seem to exist. - Greg>-----Original Message----- >From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] >Sent: Thursday, October 22, 2009 10:36 AM >To: Rose, Gregory V >Cc: xen-devel@lists.xensource.com >Subject: Re: Request for backport of 82599 quirks to 3.4.2 > >Rose, Gregory V writes ("Request for backport of 82599 quirks >to 3.4.2"): >> commit a77dc89dde1b8b9331c0f746e34389d6a253755f >> Author: Ian Jackson <ian.jackson@eu.citrix.com> >> Date: Tue Aug 4 15:28:14 2009 +0100 >> >> passthrough: support the assignment of the VF of Intel >82599 10GbE Controlle > >If I remember rightly this was a quirk of this particular card. I''d >be quite fine with putting that in the 3.4.x branch. > >Just so we are clear: these two backports both serve the same purpose >but as far as I can tell having either of them separately is no worse >than having neither ? So there''s no need to coordinate the change >across the trees ? > >Thanks, >Ian. >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2009-Oct-22 17:58 UTC
[Xen-devel] RE: Request for backport of 82599 quirks to 3.4.2
Rose, Gregory V writes ("[Xen-devel] RE: Request for backport of 82599 quirks to 3.4.2"):> Well they''re both required to pass a VF device through to a guest and then have the VF device properly reset via FLR when the guest is destroyed or shut down. If the qemu quirk to allow pass through of the VF device is committed without the associated quirk in pci.py to go ahead and issue and FLR then there is a possibility that a VF device could be left in some unknown state. It''s a low probability I think but it does seem to exist.Thanks for thinking about that. Well, I''ll hold off until Keir decides, in that case. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Oct-22 18:10 UTC
Re: [Xen-devel] RE: Request for backport of 82599 quirks to 3.4.2
On 22/10/2009 18:58, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:> Rose, Gregory V writes ("[Xen-devel] RE: Request for backport of 82599 quirks > to 3.4.2"): >> Well they''re both required to pass a VF device through to a guest and then >> have the VF device properly reset via FLR when the guest is destroyed or shut >> down. If the qemu quirk to allow pass through of the VF device is committed >> without the associated quirk in pci.py to go ahead and issue and FLR then >> there is a possibility that a VF device could be left in some unknown state. >> It''s a low probability I think but it does seem to exist. > > Thanks for thinking about that. Well, I''ll hold off until Keir > decides, in that case.The only sync points that matter in 3.4-testing now are the -rc tags. So go ahead and check it in and we''ll sync on -rc2. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel