Re: [PATCH] PCI: Make pci_find_upstream_pcie_bridge() handle non PCIE VFs well

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/09/2013 05:27 AM, Tadeusz Struk wrote:
On 01/08/2013 05:05 PM, Don Dutile wrote:

(a) no such thing as a non-PCIe VF -- all VFs
     are PCIe-based.

The sriov spec says that a VF doesn't necessarily has to have PCIE cap:
"3.5 PCI Express Capability:
    ...
    PFs and VFs are required to implement this capability ... subject to
    the exceptions and additional requirements described below"

(b) code says to return null if VF doesn't have PCIe cap,
     but the code checks if pdev is VF and if PF is PCIe,
     which it must be! ...

You are right, I should rather check if the VF is not a pcie.

Again -- nack! -- SRIOV devices must be PCIe.
Virtualization support expects VFs to be PCIe-based,
and supports things like:
(a) FLR
(b) dev-id tagged source packetting for DMA/IOMMU-mapping/filtering
(c) MSI/MSI-X only
 etc....

nack until a better&/or matching explanation of what
the real problem is, and what the solution is trying to do.

The problem is that I do have a device where VFs are not PCIE and I get this nasty warning.
For now I have a workaround, but it would be nice it Linux would support non PCIE VFs.

This is a violation of the SRIOV spec.
I do not see how we'll take a patch for violating a core specification,
and then expecting us to hack the core sriov support for it.
At best, a quirk-like hack would be entertained.

Why is this call needed by your VF (or PF) driver ?

Thanks,
T


--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux