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-devel] RE: [PATCH 3/4 v2] PCI: support SR-IOV capability

To: "Alex Chiang" <achiang@xxxxxx>
Subject: [Xen-devel] RE: [PATCH 3/4 v2] PCI: support SR-IOV capability
From: "Zhao, Yu" <yu.zhao@xxxxxxxxx>
Date: Wed, 10 Sep 2008 15:59:35 +0800
Cc: Randy Dunlap <randy.dunlap@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Grant Grundler <grundler@xxxxxxxxxxxxxxxx>, kvm@xxxxxxxxxxxxxxx, Matthew Wilcox <matthew@xxxxxx>, linux-pci@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx, Greg KH <greg@xxxxxxxxx>
Delivery-date: Wed, 10 Sep 2008 01:00:25 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080901164104.GG16796@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <7A25B56E4BE99C4283EB931CD1A40E110177EB6F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080901164104.GG16796@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckMUYt2tIuCy1AsQbuoynIuQIikzAGyRzjg
Thread-topic: [PATCH 3/4 v2] PCI: support SR-IOV capability
On Tuesday, September 02, 2008 12:41 AM, Alex Chiang wrote:
>* Zhao, Yu <yu.zhao@xxxxxxxxx>:
>> Support SR-IOV capability. By default, this feature is not enabled and the
>SR-IOV device behaves as traditional PCI device. After it's enabled, each
>Virtual Function's PCI configuration space can be accessed using its own Bus,
>Device and Function Number (Routing ID). Each Virtual Function also has PCI
>Memory Space, which is used to map its own register set.
>> Signed-off-by: Yu Zhao <yu.zhao@xxxxxxxxx>
>> Signed-off-by: Eddie Dong <eddie.dong@xxxxxxxxx>
>> ---
>>  drivers/pci/Kconfig      |   10 +
>>  drivers/pci/Makefile     |    2 +
>>  drivers/pci/iov.c        |  555
>>  drivers/pci/pci.c        |   14 +-
>>  drivers/pci/pci.h        |   44 ++++
>>  drivers/pci/probe.c      |    5 +
>>  include/linux/pci.h      |   28 +++
>>  include/linux/pci_regs.h |   20 ++
>>  8 files changed, 677 insertions(+), 1 deletions(-)
>>  create mode 100644 drivers/pci/iov.c
>So, what happens if another hotplug driver is already loaded?
>I don't know the SR-IOV spec well enough to know if you are
>allowed to have SR-IOV + some other form of hotplug, like ACPI or
>native PCIe.
>Today, pci_hp_register will return -EBUSY.
>If SR-IOV really doesn't have anything to do with hotplug, then
>it may be a candidate for directly calling pci_create_slot(). In
>that case, 'param' should not be a property of a hotplug slot,
>but of a generic PCI slot.

That's correct, SR-IOV really doesn't have anything to do with hotplug. I was 
just reusing hotplug sysfs as the control interface. Will remove this in next 
work, and create SR-IOV own sysfs entries under /sys/bus/pci/devices/.../iov/...



Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>