On Wed, 2018-09-12 at 08:02 -0500, Bjorn Helgaas wrote: > [+cc Arnd, powerpc folks] [+Oliver] > On Wed, Sep 12, 2018 at 02:34:09PM +0200, Sebastian Ott wrote: > > Hello Bjorn, > > > > On s390 we currently handle SRIOV within firmware. Which means > > that the PF is under firmware control and not visible to operating > > systems. SRIOV enablement happens within firmware and VFs are > > passed through to logical partitions. > > > > I'm working on a new mode were the PF is under operating system > > control (including SRIOV enablement). However we still need > > firmware support to access the VFs. The way this is supposed > > to work is that when firmware traps the SRIOV enablement it > > will present machine checks to the logical partition that > > triggered the SRIOV enablement and provide the VFs via hotplug > > events. > > > > The problem I'm faced with is that the VF detection code in > > sriov_enable leads to unusable functions in s390. > > We're moving away from the weak function implementation style. Can > you take a look at Arnd's work here, which uses pci_host_bridge > callbacks instead? > > https://lkml.kernel.org/r/20180817102645.3839621-1-arnd@xxxxxxxx > > I cc'd some powerpc folks because they also have a fair amount of > arch-specific SR-IOV code that might one day move in this direction. > > > Sebastian Ott (2): > > pci: provide pcibios_sriov_add_vfs > > s390/pci: handle function enumeration after sriov enablement > > > > arch/s390/pci/pci.c | 11 +++++++++++ > > drivers/pci/iov.c | 43 +++++++++++++++++++++++++++++++------------ > > include/linux/pci.h | 2 ++ > > 3 files changed, 44 insertions(+), 12 deletions(-) > > > > -- > > 2.13.4 > >
