| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[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/...
Thanks.
>
>Thanks.
>
>/ac
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home