linux-kernel - Re: [PATCH] PCI: Make pci_find_upstream_pcie

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 09 Jan 2013 11:32:44 -0500
From:	Don Dutile <ddutile@...hat.com>
To:	Tadeusz Struk <tadeusz.struk@...el.com>
CC:	bhelgaas@...gle.com, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH] PCI: Make pci_find_upstream_pcie_bridge() handle non
 PCIE VFs well

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/