linux-kernel - Re: [PATCH] uio/uio_pci_generic: Add SR-IOV support

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 28 Sep 2017 12:56:15 -0400
From:   Don Dutile <ddutile@...hat.com>
To:     David Woodhouse <dwmw2@...radead.org>,
        Alexander Duyck <alexander.duyck@...il.com>
Cc:     Bjorn Helgaas <helgaas@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-pci <linux-pci@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Alexander Duyck <alexander.h.duyck@...el.com>,
        "Bryant G. Ly" <bryantly@...ux.vnet.ibm.com>,
        Bodong Wang <bodong@...lanox.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        "Michael S. Tsirkin" <mst@...hat.com>, kvm@...r.kernel.org
Subject: Re: [PATCH] uio/uio_pci_generic: Add SR-IOV support

On 09/28/2017 11:52 AM, David Woodhouse wrote:
> On Thu, 2017-09-28 at 11:05 -0400, Don Dutile wrote:
>> ah, nickel summary: no in-kernel driver w/.sriov-configure method.
>> if so, now I'm up to speed with you....
>> hmmmm....
>> so, that would imply we need an in-kernel, pcie-common, .sriov-
>> configure method
>> that's invoked if a driver isn't bound to a device? ... yes?
>
> Well that was kind of the point in my question below the ---
>
> Is that something we want to be generic? Would we want to have quirks
> for the devices where we might *not* want it?
>
> Anything that *has* a driver for the PF, should have .sriov_configure
> already. Anything that doesn't have a driver can (now) use UIO to
> enable SR-IOV. So we don't *have* to make it unconditionally
> available...
>
Well, my point is more like: why put it in uio?
why not make it available via pcie, setup while/if no driver attached?
i.e., other non-uio users can use the mechanism.... like libvirt? ...
if a PF driver isn't required.