All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Schnelle <schnelle@linux.ibm.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Matthew Rosato <mjrosato@linux.ibm.com>,
	Pierre Morel <pmorel@linux.ibm.com>,
	linux-s390@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH RESEND 1/2] PCI: Extend isolated function probing to s390
Date: Mon, 11 Apr 2022 10:43:56 +0200	[thread overview]
Message-ID: <e565547113567e9fd6cacce333bc28d2af088b72.camel@linux.ibm.com> (raw)
In-Reply-To: <20220408224514.GA353445@bhelgaas>

[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]

On Fri, 2022-04-08 at 17:45 -0500, Bjorn Helgaas wrote:
> On Mon, Apr 04, 2022 at 11:53:45AM +0200, Niklas Schnelle wrote:
> > Like the jailhouse hypervisor s390's PCI architecture allows passing
> > isolated PCI functions to an OS instance. As of now this is was not
> > utilized even with multi-function support as the s390 PCI code makes
> > sure that only virtual PCI busses including a function with devfn 0 are
> > presented to the PCI subsystem. A subsequent change will remove this
> > restriction.
> > 
> > Allow probing such functions by replacing the existing check for
> > jailhouse_paravirt() with a new hypervisor_isolated_pci_functions()
> > helper.
> > 
> > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> 
> I'm OK with the idea of generalizing this Jailhouse test, but I wonder
> if this check should be in pci_scan_slot() rather than in
> pci_scan_child_bus_extend().
> 
> I think the idea is that pci_scan_slot() should find all the functions
> of a device (a.k.a. "slot"), so it's a little weird to have a loop
> calling pci_scan_single_device() for each function in both places.

Yeah, I agree.
> 
> Currently we never call pcie_aspm_init_link_state() for these
> Jailhouse or s390 functions.  Maybe that's OK (and I think
> pci_scan_slot() is the wrong place to initialize ASPM anyway) but if
> we could move the Jailhouse/s390 checking to pci_scan_slot(), it would
> at least remove the inconsistency.
> 
> I'm thinking something along the lines of the patch below.  I'm sure
> Jan considered this originally, so maybe there's some reason this
> won't work.

One thing I already noticed is that I think next_fn() may need to be
changed. If pci_ari_enabled(bus) is true, then it immediately returns 0
on dev == NULL while if it is false there is an extra check for non-
contiguous multifunction devices. Even then I think on jailhouse() dev-
>multifunction might not be set at that point. This is in contrast to
s390 where we set dev->multifunction based on information provided by
the platform before scanning the bus. So I'll have to be careful not to
create a state where this works on s390 but might not work for
jailhouse.

I also do wonder what the role of the PCI_SCAN_ALL_PCIE_DEVS flag
should be here. At least the comment in only_one_child() sounds a lot
like that flag kind of indicates the same thing.

I'll do some more investigation and testing and report back. I do agree
that there seems to be some potential for cleanup here.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2022-04-11  8:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-04  9:53 [PATCH RESEND 1/2] PCI: Extend isolated function probing to s390 Niklas Schnelle
2022-04-04  9:53 ` [PATCH RESEND 2/2] s390/pci: allow zPCI zbus without a function zero Niklas Schnelle
2022-04-08 22:45 ` [PATCH RESEND 1/2] PCI: Extend isolated function probing to s390 Bjorn Helgaas
2022-04-11  8:43   ` Niklas Schnelle [this message]
2022-04-11 19:23     ` Bjorn Helgaas
2022-04-12 11:59       ` Niklas Schnelle

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=e565547113567e9fd6cacce333bc28d2af088b72.camel@linux.ibm.com \
    --to=schnelle@linux.ibm.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=jan.kiszka@siemens.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjrosato@linux.ibm.com \
    --cc=pmorel@linux.ibm.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.