| Message ID | 20180912123411.23229-1-sebott@linux.ibm.com |
|---|---|
| Headers | show |
| Series | sriov enablement on s390 | expand |
[+cc Arnd, powerpc folks] 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@arndb.de 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 >
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@arndb.de > > 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 > >
On Wed, 12 Sep 2018, Bjorn Helgaas wrote: > [+cc Arnd, powerpc folks] > > 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@arndb.de > > 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. Rebased to Arnd's pci-probe-rework branch. Sebastian Ott (2): pci: provide add_vfs/del_vfs callbacks s390/pci: handle function enumeration after sriov enablement arch/s390/pci/pci.c | 11 +++++++++++ drivers/pci/iov.c | 51 +++++++++++++++++++++++++++++++++++++++------------ include/linux/pci.h | 2 ++ 3 files changed, 52 insertions(+), 12 deletions(-)
Hello Bjorn, On Wed, 12 Sep 2018, Bjorn Helgaas wrote: > On Wed, Sep 12, 2018 at 02:34:09PM +0200, Sebastian Ott wrote: > > 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@arndb.de What's the status of Arnd's patches - will they go upstream in the next couple of versions? What about my patches that I rebased on Arnd's branch will they be considered? Regards, Sebastian
On Wed, Oct 10, 2018 at 02:55:07PM +0200, Sebastian Ott wrote: > Hello Bjorn, > > On Wed, 12 Sep 2018, Bjorn Helgaas wrote: > > On Wed, Sep 12, 2018 at 02:34:09PM +0200, Sebastian Ott wrote: > > > 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@arndb.de > > What's the status of Arnd's patches - will they go upstream in the next > couple of versions? I hope so [1]. IIRC Arnd mentioned doing some minor updates, so I'm waiting on that. > What about my patches that I rebased on Arnd's branch > will they be considered? Definitely. From my point of view they're just lined up behind Arnd's patches. [1] https://lore.kernel.org/linux-pci/20181002205903.GD120535@bhelgaas-glaptop.roam.corp.google.com
Hello Bjorn, On Wed, 10 Oct 2018, Bjorn Helgaas wrote: > On Wed, Oct 10, 2018 at 02:55:07PM +0200, Sebastian Ott wrote: > > On Wed, 12 Sep 2018, Bjorn Helgaas wrote: > > > On Wed, Sep 12, 2018 at 02:34:09PM +0200, Sebastian Ott wrote: > > > > 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@arndb.de > > > > What's the status of Arnd's patches - will they go upstream in the next > > couple of versions? > > I hope so [1]. IIRC Arnd mentioned doing some minor updates, so I'm > waiting on that. > > > What about my patches that I rebased on Arnd's branch > > will they be considered? > > Definitely. From my point of view they're just lined up behind Arnd's > patches. > > [1] https://lore.kernel.org/linux-pci/20181002205903.GD120535@bhelgaas-glaptop.roam.corp.google.com It appears like these patches are not in-line for the next merge window. Would it be possible to go with my original patches (using __weak functions)? (This would also make life easier with regards to backports) I can post patches to convert this to use function pointers once Arnd's patches make it to the kernel. Regards, Sebastian
On Wed, Dec 05, 2018 at 02:45:14PM +0100, Sebastian Ott wrote: > Hello Bjorn, > > On Wed, 10 Oct 2018, Bjorn Helgaas wrote: > > On Wed, Oct 10, 2018 at 02:55:07PM +0200, Sebastian Ott wrote: > > > On Wed, 12 Sep 2018, Bjorn Helgaas wrote: > > > > On Wed, Sep 12, 2018 at 02:34:09PM +0200, Sebastian Ott wrote: > > > > > 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@arndb.de > > > > > > What's the status of Arnd's patches - will they go upstream in the next > > > couple of versions? > > > > I hope so [1]. IIRC Arnd mentioned doing some minor updates, so I'm > > waiting on that. > > > > > What about my patches that I rebased on Arnd's branch > > > will they be considered? > > > > Definitely. From my point of view they're just lined up behind Arnd's > > patches. > > > > [1] https://lore.kernel.org/linux-pci/20181002205903.GD120535@bhelgaas-glaptop.roam.corp.google.com > > It appears like these patches are not in-line for the next merge window. > Would it be possible to go with my original patches (using __weak > functions)? (This would also make life easier with regards to backports) > I can post patches to convert this to use function pointers once Arnd's > patches make it to the kernel. Yeah, sorry, I think we should just go with your original approach. Can you repost those patches with minor changelog updates so "git log --online" on the files looks consistent. Also, capitalize "PCI", "VF", etc, consistently when used in English text. Bjorn