From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Julien Grall <julien@xen.org>,
Michal Orzel <michal.orzel@amd.com>,
Stefano Stabellini <sstabellini@kernel.org>,
Bertrand Marquis <bertrand.marquis@arm.com>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Oleksii Kurochko <oleksii.kurochko@gmail.com>,
Volodymyr Babchuk <volodymyr_babchuk@epam.com>
Subject: Re: [PATCH v2 for-4.20? 6/6] PCI: drop pci_segments_init()
Date: Tue, 4 Feb 2025 09:56:52 +0100 [thread overview]
Message-ID: <Z6HWVDP3lL0-Y38T@macbook.local> (raw)
In-Reply-To: <afaff8bf-41c5-4c80-a24d-3ce748b52a6a@suse.com>
On Tue, Feb 04, 2025 at 08:51:10AM +0100, Jan Beulich wrote:
> On 04.02.2025 08:45, Jan Beulich wrote:
> > On 03.02.2025 18:18, Roger Pau Monné wrote:
> >> On Mon, Feb 03, 2025 at 05:27:24PM +0100, Jan Beulich wrote:
> >>> --- a/xen/arch/x86/x86_64/mmconfig-shared.c
> >>> +++ b/xen/arch/x86/x86_64/mmconfig-shared.c
> >>> @@ -402,6 +402,9 @@ void __init acpi_mmcfg_init(void)
> >>> {
> >>> bool valid = true;
> >>>
> >>> + if ( pci_add_segment(0) )
> >>> + panic("Could not initialize PCI segment 0\n");
> >>
> >> Do you still need the pci_add_segment() call here?
> >>
> >> pci_add_device() will already add the segments as required, and
> >> acpi_parse_mcfg() does also add the segments described in the MCFG.
> >
> > Well, in principle you're right. It's more the action in case of
> > failure that makes me want to keep it: We won't fare very well on
> > about every system if we can't register segment 0.
pci_add_segment() should only fail due to being out of memory, and I'm
quite sure if pci_add_segment() was to fail here due to out of memory
issues Xen won't be able to complete booting anyway.
Note the usage of "should only fail", as it's possible for
radix_tree_insert() to return -EEXIST, but that shouldn't be possible
given alloc_pseg() checks whether the segment is already added.
> Thinking about it: Your question may be more applicable on Arm, as I'm
> entirely uncertain whether there segment 0 is always going to be needed.
> I could well imagine system designers deliberately putting all the
> devices elsewhere. Segment 0 always being in use on x86 is more a
> heritage thing, after all.
I guess I would leave that one to the Arm maintainers, but from my
knowledge I got the impression is fairly common for Arm to have
multiple segments, not sure whether it's also common to start at
segment 0.
I'm not strongly opposed to leaving the pci_add_segment(0) call on
x86, but I would recommend prepending a small comment to note adding
the segment is not strictly required; it's just done for better error
reporting, as other callers that add PCI segments might silently
ignore the failure to add segment 0.
An unrelated question: looking at MCFG handling I've noticed that
calling PHYSDEVOP_pci_mmcfg_reserved doesn't seem to result in the
segment being added. Is it on purpose that pci_mmcfg_reserved()
doesn't attempt to allocate the hardware domain discovered segment?
Thanks, Roger.
next prev parent reply other threads:[~2025-02-04 8:57 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-03 16:22 [PATCH for-4.20 0/6] AMD/IOMMU: assorted corrections Jan Beulich
2025-02-03 16:24 ` [PATCH v2 for-4.20? 1/6] AMD/IOMMU: drop stray MSI enabling Jan Beulich
2025-02-03 16:54 ` Roger Pau Monné
2025-02-03 16:24 ` [PATCH v2 for-4.20 2/6] x86/PCI: init segments earlier Jan Beulich
2025-02-03 16:25 ` [PATCH v2 for-4.20 3/6] radix-tree: purge node allocation override hooks Jan Beulich
2025-02-03 16:29 ` Jan Beulich
2025-02-03 16:36 ` Andrew Cooper
2025-02-03 16:25 ` [PATCH v2 for-4.21 4/6] radix-tree: drop "root" parameters from radix_tree_node_{alloc,free}() Jan Beulich
2025-02-03 16:40 ` Andrew Cooper
2025-02-03 16:26 ` [PATCH v2 for-4.20? 5/6] radix-tree: introduce RADIX_TREE{,_INIT}() Jan Beulich
2025-02-03 16:48 ` Andrew Cooper
2025-02-03 16:58 ` Jan Beulich
2025-02-04 8:36 ` Jan Beulich
2025-02-04 8:45 ` Jan Beulich
2025-02-04 11:19 ` Andrew Cooper
2025-02-03 16:27 ` [PATCH v2 for-4.20? 6/6] PCI: drop pci_segments_init() Jan Beulich
2025-02-03 17:04 ` Andrew Cooper
2025-02-04 7:17 ` Jan Beulich
2025-02-03 17:18 ` Roger Pau Monné
2025-02-04 7:45 ` Jan Beulich
2025-02-04 7:51 ` Jan Beulich
2025-02-04 8:56 ` Roger Pau Monné [this message]
2025-02-04 9:53 ` Jan Beulich
2025-02-03 16:38 ` [PATCH for-4.20 0/6] AMD/IOMMU: assorted corrections Oleksii Kurochko
2025-02-03 16:55 ` Andrew Cooper
2025-02-04 7:14 ` Jan Beulich
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=Z6HWVDP3lL0-Y38T@macbook.local \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=bertrand.marquis@arm.com \
--cc=jbeulich@suse.com \
--cc=julien@xen.org \
--cc=michal.orzel@amd.com \
--cc=oleksii.kurochko@gmail.com \
--cc=sstabellini@kernel.org \
--cc=volodymyr_babchuk@epam.com \
--cc=xen-devel@lists.xenproject.org \
/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.