From: "Michael S. Tsirkin" <mst@redhat.com>
To: Akihiko Odaki <akihiko.odaki@daynix.com>
Cc: "Cédric Le Goater" <clg@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
"Sriram Yagnaraman" <sriram.yagnaraman@ericsson.com>,
"Jason Wang" <jasowang@redhat.com>,
"Keith Busch" <kbusch@kernel.org>,
"Klaus Jensen" <its@irrelevant.dk>,
"Markus Armbruster" <armbru@redhat.com>,
"Matthew Rosato" <mjrosato@linux.ibm.com>,
"Eric Farman" <farman@linux.ibm.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [PATCH for-9.2 v15 04/11] s390x/pci: Check for multifunction after device realization
Date: Wed, 11 Sep 2024 07:23:25 -0400 [thread overview]
Message-ID: <20240911072301-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <eaebda7d-c61e-4ed8-a6b9-98e5f48f26ff@daynix.com>
On Wed, Sep 11, 2024 at 07:58:15PM +0900, Akihiko Odaki wrote:
> On 2024/09/11 18:38, Cédric Le Goater wrote:
> > +Matthew +Eric
> >
> > Side note for the maintainers :
> >
> > Before this change, the igb device, which is multifunction, was working
> > fine under Linux.
> >
> > Was there a fix in Linux since :
> >
> > 57da367b9ec4 ("s390x/pci: forbid multifunction pci device")
> > 6069bcdeacee ("s390x/pci: Move some hotplug checks to the pre_plug
> > handler")
> >
> > ?
> >
> > s390 PCI devices do not have extended capabilities, so the igb device
> > does not expose the SRIOV capability and only the PF is accessible but
> > it doesn't seem to be an issue. (Btw, CONFIG_PCI_IOV is set to y in the
> > default Linux config which is unexpected)
>
> Doesn't s390x really see extended capabilities? hw/s390x/s390-pci-inst.c has
> a call pci_config_size() and pci_host_config_write_common(), which means it
> is exposing the whole PCI Express configuration space. Why can't s390x use
> extended capabilities then?
>
> The best option for fix would be to replace the SR-IOV implementation with
> stub if s390x cannot use the SR-IOV capability. However I still need to know
> at what level I should change the implementation (e.g., is it fine to remove
> the entire capability, or should I keep the capability while writes to its
> registers no-op?)
>
> Regards,
> Akihiko Odaki
Note changing caps needs compat hacks for cross version migration to work.
> >
> > Thanks,
> >
> > C.
> >
> >
> >
> > On 8/23/24 07:00, Akihiko Odaki wrote:
> > > The SR-IOV PFs set the multifunction bits during device realization so
> > > check them after that. This forbids adding SR-IOV devices to s390x.
> > >
> > > Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
> > > ---
> > > hw/s390x/s390-pci-bus.c | 14 ++++++--------
> > > 1 file changed, 6 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/hw/s390x/s390-pci-bus.c b/hw/s390x/s390-pci-bus.c
> > > index 3e57d5faca18..00b2c1f6157b 100644
> > > --- a/hw/s390x/s390-pci-bus.c
> > > +++ b/hw/s390x/s390-pci-bus.c
> > > @@ -971,14 +971,7 @@ static void
> > > s390_pcihost_pre_plug(HotplugHandler *hotplug_dev, DeviceState *dev,
> > > "this device");
> > > }
> > > - if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
> > > - PCIDevice *pdev = PCI_DEVICE(dev);
> > > -
> > > - if (pdev->cap_present & QEMU_PCI_CAP_MULTIFUNCTION) {
> > > - error_setg(errp, "multifunction not supported in s390");
> > > - return;
> > > - }
> > > - } else if (object_dynamic_cast(OBJECT(dev), TYPE_S390_PCI_DEVICE)) {
> > > + if (object_dynamic_cast(OBJECT(dev), TYPE_S390_PCI_DEVICE)) {
> > > S390PCIBusDevice *pbdev = S390_PCI_DEVICE(dev);
> > > if (!s390_pci_alloc_idx(s, pbdev)) {
> > > @@ -1069,6 +1062,11 @@ static void s390_pcihost_plug(HotplugHandler
> > > *hotplug_dev, DeviceState *dev,
> > > } else if (object_dynamic_cast(OBJECT(dev), TYPE_PCI_DEVICE)) {
> > > pdev = PCI_DEVICE(dev);
> > > + if (pdev->cap_present & QEMU_PCI_CAP_MULTIFUNCTION) {
> > > + error_setg(errp, "multifunction not supported in s390");
> > > + return;
> > > + }
> > > +
> > > if (!dev->id) {
> > > /* In the case the PCI device does not define an id */
> > > /* we generate one based on the PCI address */
> > >
> >
next prev parent reply other threads:[~2024-09-11 11:24 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-23 5:00 [PATCH for-9.2 v15 00/11] hw/pci: SR-IOV related fixes and improvements Akihiko Odaki
2024-08-23 5:00 ` [PATCH for-9.2 v15 01/11] hw/pci: Rename has_power to enabled Akihiko Odaki
2024-08-23 5:00 ` [PATCH for-9.2 v15 02/11] hw/ppc/spapr_pci: Do not create DT for disabled PCI device Akihiko Odaki
2024-08-23 5:00 ` [PATCH for-9.2 v15 03/11] hw/ppc/spapr_pci: Do not reject VFs created after a PF Akihiko Odaki
2024-08-23 5:00 ` [PATCH for-9.2 v15 04/11] s390x/pci: Check for multifunction after device realization Akihiko Odaki
2024-09-10 13:22 ` Cédric Le Goater
2024-09-11 9:38 ` Cédric Le Goater
2024-09-11 10:58 ` Akihiko Odaki
2024-09-11 11:23 ` Michael S. Tsirkin [this message]
2024-09-11 13:53 ` Matthew Rosato
2024-09-11 15:15 ` Akihiko Odaki
2024-09-11 21:11 ` Matthew Rosato
2024-09-12 6:40 ` Akihiko Odaki
2024-08-23 5:00 ` [PATCH for-9.2 v15 05/11] pcie_sriov: Do not manually unrealize Akihiko Odaki
2024-08-23 5:00 ` [PATCH for-9.2 v15 06/11] pcie_sriov: Reuse SR-IOV VF device instances Akihiko Odaki
2024-08-23 5:00 ` [PATCH for-9.2 v15 07/11] pcie_sriov: Release VFs failed to realize Akihiko Odaki
2024-08-23 5:00 ` [PATCH for-9.2 v15 08/11] pcie_sriov: Remove num_vfs from PCIESriovPF Akihiko Odaki
2024-08-23 5:00 ` [PATCH for-9.2 v15 09/11] pcie_sriov: Register VFs after migration Akihiko Odaki
2024-08-23 5:00 ` [PATCH for-9.2 v15 10/11] hw/pci: Use -1 as the default value for rombar Akihiko Odaki
2024-08-23 5:00 ` [PATCH for-9.2 v15 11/11] hw/qdev: Remove opts member Akihiko Odaki
2024-09-10 9:21 ` [PATCH for-9.2 v15 00/11] hw/pci: SR-IOV related fixes and improvements Michael S. Tsirkin
2024-09-10 9:33 ` Akihiko Odaki
2024-09-10 11:47 ` Michael S. Tsirkin
2024-09-10 13:21 ` Cédric Le Goater
2024-09-10 13:34 ` Michael S. Tsirkin
2024-09-10 14:13 ` Cédric Le Goater
2024-09-10 15:27 ` Michael S. Tsirkin
2024-09-11 3:05 ` Akihiko Odaki
2024-09-11 10:00 ` Michael S. Tsirkin
2024-09-11 10:09 ` Cédric Le Goater
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240911072301-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=akihiko.odaki@daynix.com \
--cc=alex.williamson@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=clg@redhat.com \
--cc=eduardo@habkost.net \
--cc=farman@linux.ibm.com \
--cc=its@irrelevant.dk \
--cc=jasowang@redhat.com \
--cc=kbusch@kernel.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=mjrosato@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sriram.yagnaraman@ericsson.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.