[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] PCI: drop pci_segments_init()


  • To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
  • Date: Wed, 26 Feb 2025 14:57:30 -0500
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=suse.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=84IQsjRhbhJrCp2aAXmYEDyJB0YeW06zMc8kMk8us4o=; b=XAHG9w6Ahzeygco0nmZhw48bHCPV52kcSMU7H3h0CTHs6CypGGL+nFAqa1gEhZSpIhjqDQ1cZuMPdakXRbef/rnjqZL/9hHqSMVSSrKres3NaFE3TM8NiCXkITS5RK7rIFxbTTN7bO+k2Wlngw5XdEaEvq6tU1qeulOdekZMCVojfojbwaPEuGenqgZFTyYdpsb8h6pEjNATlhRV93SnQJHmhKsbHfe3arHU+I2S9WkvjjbD6B9cBo2Eyd+Q55tLY6Vo5fcX7eM22KkYJillS6OiIP2yjKfbOvv0bfxt9pZluSfK87r51UUgJR9/AKeirONvE+SW8gcnvFq1qI6IKQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mIsprvmPcSrSqjgpy4GRhjUXUdao+pORGP2NSm7P9Zc1RJgqsDUGEtv/msRkcNn8p8YVdkcsE+aLZO4f6h+hRHM8fCPiEPvy207nmkB+K+WmPoNW2Zd34HUM/Q+HdEKabfgYf4ba04vN73oW0eGfkwWoHeCk2XDt6PAlYZH00OhpiPH4HzQYnu2OlrFLGvA1IkpwJTY2mQMRC2cHSbFLbxWBdowTLRCOxJYuYgkU4AzkKa7W6cloG6EuGal5tYE/oWRzRBQO1ZboxCG9BIVnd6aDvieyS13aewpbUd5JAKbV32Cb9rd5mxBIOlCyc0pXwTzK8iLHc0993NToGwBkjg==
  • Cc: Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Anthony Perard <anthony@xxxxxxxxxxxxxx>
  • Delivery-date: Wed, 26 Feb 2025 19:58:06 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 2/26/25 06:38, Jan Beulich wrote:
> Have callers invoke pci_add_segment() directly instead: With radix tree
> initialization moved out of the function, its name isn't quite
> describing anymore what it actually does.
> 
> On x86 move the logic into __start_xen() itself, to reduce the risk of
> re-introducing ordering issues like the one which was addressed by
> 26fe09e34566 ("radix-tree: introduce RADIX_TREE{,_INIT}()").
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> This is entirely optional and up for discussion. There certainly also is
> an argument towards keeping the function. Otoh on Arm there is the still
> open question whether segment 0 really is kind of special there (as it
> is on x86, largely for historical reasons), or whether the code can be
> dropped there altogether.

Segment 0 is not special on Arm as far as I'm aware. You can have a
perfectly functioning system with only, say, segment 1, for example:

(XEN) ==== PCI devices ====
(XEN) ==== segment 0001 ====
(XEN) 0001:00:01.0 - d0 - node -1
(XEN) 0001:00:00.0 - d0 - node -1

Segment numbers can be arbitrarily chosen by specifying the
linux,pci-domain device tree property.

> ---
> v4: Move x86 logic into __start_xen() itself.
> v3: Adjust description to account for and re-base over dropped earlier
>     patch.
> v2: New.
> 
> --- a/xen/arch/arm/pci/pci.c
> +++ b/xen/arch/arm/pci/pci.c
> @@ -88,7 +88,8 @@ static int __init pci_init(void)
>      if ( !pci_passthrough_enabled )
>          return 0;
>  
> -    pci_segments_init();
> +    if ( pci_add_segment(0) )
> +        panic("Could not initialize PCI segment 0\n");

IMO it's okay to remove the call here since there is already a call to
pci_add_segment() in
xen/arch/arm/pci/pci-host-common.c:pci_host_common_probe()

If there happens to be an Arm SoC with segment number quirks, that
could be worked out in a SoC-specific xen/arch/arm/pci/pci-host-*.c.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.