[Xen-devel] RE: [PATCH 3/4 v2] PCI: support SR-IOV capability

["Zhao, Yu" <yu.zhao@xxxxxxxxx>]

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