Greetings, Following patches enable Xen to support SR-IOV capability. PCI device with the capability can be turned into multiple ones from software perspective, thus user can assign these Virtual Functions to HVM and PV guest. [PATCH 1/9] dom0 PCI: export some functions and macros [PATCH 2/9] dom0 PCI: add new general functions [PATCH 3/9] dom0 PCI: support ARI capability [PATCH 4/9] dom0 PCI: support SR-IOV capability [PATCH 5/9] dom0 PCI: reserve bus range for SR-IOV device [PATCH 6/9] dom0 PCI: document the change [PATCH 7/9] dom0 PCI backend: enable PV guest SR-IOV support [PATCH 8/9] qemue: enable HMV guest SR-IOV support [PATCH 9/9] xen: add SR-IOV support to xm Documentation/DocBook/kernel-api.tmpl | 2 Documentation/PCI/pci-iov-howto.txt | 227 ++++++++ drivers/pci/iov.c | 832 ++++++++++++++++++++++++++++++++ hw/pass-through.c | 81 +++ drivers/pci/Kconfig | 11 drivers/pci/Makefile | 2 drivers/pci/iov.c | 24 drivers/pci/pci-sysfs.c | 19 drivers/pci/pci.c | 107 +++- drivers/pci/pci.h | 95 +++ drivers/pci/probe.c | 238 +++++---- drivers/pci/proc.c | 7 drivers/pci/setup-bus.c | 4 drivers/pci/setup-res.c | 31 - drivers/xen/pciback/conf_space_header.c | 71 ++ include/linux/pci.h | 99 +++ include/linux/pci_regs.h | 36 + tools/python/xen/util/pci.py | 177 ++++++ tools/python/xen/xm/main.py | 40 + 19 files changed, 1937 insertions(+), 166 deletions(-) --- Single Root I/O Virtualization (SR-IOV) capability defined by PCI-SIG is intended to enable multiple system software to share PCI hardware resources. PCI device that supports this capability can be extended to one Physical Functions plus multiple Virtual Functions. Physical Function, which could be considered as the "real" PCI device, reflects the hardware instance and manages all physical resources. Virtual Functions are associated with a Physical Function and shares physical resources with the Physical Function. Software can control allocation of Virtual Functions via registers encapsulated in the capability structure. SR-IOV specification can be found at http://www.pcisig.com/members/downloads/specifications/iov/sr-iov1.0_11Sep07.pdf Devices that support SR-IOV are available from following vendors: http://download.intel.com/design/network/ProdBrf/320025.pdf http://www.netxen.com/products/chipsolutions/NX3031.html http://www.neterion.com/products/x3100.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 27/9/08 09:58, "Zhao, Yu" <yu.zhao@intel.com> wrote:> Greetings, > > Following patches enable Xen to support SR-IOV capability. PCI device with the > capability can be turned into multiple ones from software perspective, thus > user can assign these Virtual Functions to HVM and PV guest.These patches are corrupt (most obvious example is that all tabs have been turned into spaces), hence they do not apply. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Apparently not all of this code is really written from scratch - would it be possible to indicate which pieces are really backports or adoptions of mainline Linux code? Thanks, Jan>>> "Zhao, Yu" <yu.zhao@intel.com> 27.09.08 10:58 >>>Greetings, Following patches enable Xen to support SR-IOV capability. PCI device with the capability can be turned into multiple ones from software perspective, thus user can assign these Virtual Functions to HVM and PV guest. [PATCH 1/9] dom0 PCI: export some functions and macros [PATCH 2/9] dom0 PCI: add new general functions [PATCH 3/9] dom0 PCI: support ARI capability [PATCH 4/9] dom0 PCI: support SR-IOV capability [PATCH 5/9] dom0 PCI: reserve bus range for SR-IOV device [PATCH 6/9] dom0 PCI: document the change [PATCH 7/9] dom0 PCI backend: enable PV guest SR-IOV support [PATCH 8/9] qemue: enable HMV guest SR-IOV support [PATCH 9/9] xen: add SR-IOV support to xm Documentation/DocBook/kernel-api.tmpl | 2 Documentation/PCI/pci-iov-howto.txt | 227 ++++++++ drivers/pci/iov.c | 832 ++++++++++++++++++++++++++++++++ hw/pass-through.c | 81 +++ drivers/pci/Kconfig | 11 drivers/pci/Makefile | 2 drivers/pci/iov.c | 24 drivers/pci/pci-sysfs.c | 19 drivers/pci/pci.c | 107 +++- drivers/pci/pci.h | 95 +++ drivers/pci/probe.c | 238 +++++---- drivers/pci/proc.c | 7 drivers/pci/setup-bus.c | 4 drivers/pci/setup-res.c | 31 - drivers/xen/pciback/conf_space_header.c | 71 ++ include/linux/pci.h | 99 +++ include/linux/pci_regs.h | 36 + tools/python/xen/util/pci.py | 177 ++++++ tools/python/xen/xm/main.py | 40 + 19 files changed, 1937 insertions(+), 166 deletions(-) --- Single Root I/O Virtualization (SR-IOV) capability defined by PCI-SIG is intended to enable multiple system software to share PCI hardware resources. PCI device that supports this capability can be extended to one Physical Functions plus multiple Virtual Functions. Physical Function, which could be considered as the "real" PCI device, reflects the hardware instance and manages all physical resources. Virtual Functions are associated with a Physical Function and shares physical resources with the Physical Function. Software can control allocation of Virtual Functions via registers encapsulated in the capability structure. SR-IOV specification can be found at http://www.pcisig.com/members/downloads/specifications/iov/sr-iov1.0_11Sep07.pdf Devices that support SR-IOV are available from following vendors: http://download.intel.com/design/network/ProdBrf/320025.pdf http://www.netxen.com/products/chipsolutions/NX3031.html http://www.neterion.com/products/x3100.html _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jan Beulich writes ("Re: [Xen-devel] [PATCH 0/9] PCI SR-IOV
support"):> Apparently not all of this code is really written from scratch - would it
be
> possible to indicate which pieces are really backports or adoptions of
> mainline Linux code?
That''s rather worrying. Which parts did you see that were not written
from scratch ?
The Signed-Off-By line that appears in these patches is supposed to be
the poster certifying the origin of the code. See the `Developers
Certificate of Origin'', below:
It would be a violation of the original copyright to cut-and-paste
code from the Linux kernel, remove the copyright notices, and post it
here.
When code is submitted for inclusion in Xen, but was obtained from
some other source, that source should be clearly identified so that
the origin can be traced, credit given, and so on.
Ian.
>From Documentation/SubmittingPatches in the Linux tree:
Developer''s Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
--
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
>>> Ian Jackson <Ian.Jackson@eu.citrix.com> 29.09.08 17:52 >>> >Jan Beulich writes ("Re: [Xen-devel] [PATCH 0/9] PCI SR-IOV support"): >> Apparently not all of this code is really written from scratch - would it be >> possible to indicate which pieces are really backports or adoptions of >>> mainline Linux code? > >That''s rather worrying. Which parts did you see that were not written >from scratch ?Without checking specifics again - I just looked at some of the manifest constant names, enumeration types, etc., to find almost everything in current (2.6.27-rc7) kernel sources. I stopped looking further pretty quickly as it seemed easier (and more correct as you also point out) to ask the author to supply proper references if the code was indeed derived. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel