linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiang Liu <jiang.liu@huawei.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>,
	Yinghai Lu <yinghai@kernel.org>,
	Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>,
	Don Dutile <ddutile@redhat.com>, Jiang Liu <liuj97@gmail.com>,
	Yijing Wang <wangyijing@huawei.com>,
	Keping Chen <chenkeping@huawei.com>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH v6 0/9] PCI, x86: update MMCFG information when hot-plugging PCI host bridges
Date: Fri, 25 May 2012 10:21:52 +0800	[thread overview]
Message-ID: <4FBEECC0.5040108@huawei.com> (raw)
In-Reply-To: <20120524182601.GA7551@google.com>

On 2012-5-25 2:26, Bjorn Helgaas wrote:
> On Wed, May 23, 2012 at 11:50:17AM +0800, Jiang Liu wrote:
>> From: Jiang Liu<liuj97@gmail.com>
>>
>> From: Jiang Liu<jiang.liu@huawei.com>
>>
>> This patchset enhance pci_root driver to update MMCFG information when
>> hot-plugging PCI root bridges. It applies to
>> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/next-3.5
>>
>> -v2: split into smaller patches and skip updating MMCFG information when
>>       MMCFG is disabled
>> -v3: add mmconf_added to simply free path, also make pci_mmconfig_insert()
>>       to process extra exist case --- By Yinghai
>> -v4: tune arch_acpi_pci_root_add() to handle a corner case raised by Kenji
>> -v5: address review comments from Bjorn and Taku, also better handle corner
>>       cases in arch_acpi_pci_root_add()
>> -v6: get rid of arch_acpi_pci_root_xxx() by using existing hooks
>>       add MCFG information for host bridges on demand
>>       more corner cases clear up
>>       correctly handle condition compilation
>>       fix section mismatch issues
>>       fix a issue reported by Taku about a BIOS bug
>>
>> The first 4 patches in series is the same with v5.
>
> I tried this on one of my machines.  Before your patches:
>
>      ACPI: bus type pci registered
>      PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000)
>      PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820
>      ...
>      ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7e])
>
> After:
>
>      ACPI: bus type pci registered
> 1)  PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0x80000000-0x8fffffff] (base 0x80000000)
>      PCI: MMCONFIG at [mem 0x80000000-0x8fffffff] reserved in E820
>      ...
>      ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7e])
> 2)  PCI: MMCONFIG for domain 0000 [bus 00-7e] at [mem 0x80000000-0x87efffff] (base 0x80000000)
> 3)  [Firmware Bug]: PCI: MMCONFIG at [mem 0x80000000-0x87efffff] not reserved in ACPI motherboard resources
> 4)  PCI: MMCONFIG at [mem 0x80000000-0x87efffff] reserved in E820
>
> I really like the MMCONFIG info being associated with the host bridge in
> dmesg, and I really like it being split out in /proc/iomem.  That's much
> cleaner than it used to be.  MMCONFIG is defined by the PCIe spec, and
> there are non-x86 architectures that use the same mechanism, so I can
> imagine someday (not now!) making it more generic.
>
> 1): Do we really need this early MCFG scan?  Conceptually it seems like we
> don't need to look at MCFG until we add a host bridge or do a blind probe.
After digging the log messages, I found the early probing logic is
needed for two cases:
1) CONFIG_PCI_BIOS and CONFIG_PCI_DIRECT are disabled or not supported
by the platform, and MMCONF is the only method to access configuration
space. So need to support MMCONF as early as possible because ACPI
initialization may need to access PCI configuration space.

2) ACPI is disabled by "acpi=off" boot option or due to errors when 
initializing the ACPI subsystem, so pci_mmcfg_late_init() won't be called.

So it seems we do need the early probe logic.

>
> 2) and 4): These should be dev_info() with the host bridge device, e.g.,
>
>      pci_root PNP0A08:00: MMCONFIG at [mem 0x80000000-0x87efffff]
>
> Now that we can associate it with the bridge, the bus number range is
> redundant.  It might be useful to know whether the MMCONFIG range came from
> _CBA or MCFG, if that's easy to do.
>
> Here's I'm thinking: right now we have some message confusion -- the arch
> prints window info, e.g., "pci_root PNP0A08:00: host bridge window [io
> 0x0000-0x03af]", and then the PCI core prints the same thing but associated
> with the bus: "pci_bus 0000:00: root bus resource [io  0x0000-0x03af]".
> I'd like this to become more uniform, and have only the core print it, but
> using the host bridge device, not the bus.
OK, will change the log messages according to your suggestions.

>
> 3): Something seems wrong here -- this "bug" message didn't appear before,
> so I don't think it should now.  I haven't tried to chase this down.
__pci_mmcfg_init() will be called by pci_mmcfg_early_init() and
pci_mmcfg_late_init(). When it's called by pci_mmcfg_early_init(),
the ACPI subsystem hasn't been initialized yet, so
pci_mmcfg_reject_broken() doesn't check whether the resource is
reserved by ACPI motherboard devices. If we pass "pci=noearly"
option to the kernel to disable early probe, it will generate
the warning message on the same platform.

According to commit 7752d5cfe3d11ca0bb9c673ec38bd78ba6578f8e log
message, "The PCI Express firmware spec apparently tells BIOS
developers that reservation in ACPI is required and E820 reservation
is optional", it would be better for us to emit this warning message.
Any suggestions here?





  parent reply	other threads:[~2012-05-25  2:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-23  3:50 [PATCH v6 0/9] PCI, x86: update MMCFG information when hot-plugging PCI host bridges Jiang Liu
2012-05-23  3:50 ` [PATCH v6 1/9] PCI, x86: split out pci_mmcfg_check_reserved() for code reuse Jiang Liu
2012-05-23  3:50 ` [PATCH v6 2/9] PCI, x86: split out pci_mmconfig_alloc() " Jiang Liu
2012-05-23  3:50 ` [PATCH v6 3/9] PCI, x86: use RCU list to protect mmconfig list Jiang Liu
2012-05-23  3:50 ` [PATCH v6 4/9] PCI, x86: introduce pci_mmcfg_arch_map()/pci_mmcfg_arch_unmap() Jiang Liu
2012-05-23  3:50 ` [PATCH v6 5/9] PCI, x86: introduce pci_mmconfig_insert()/delete() for PCI root bridge hotplug Jiang Liu
2012-05-23  3:50 ` [PATCH v6 6/9] PCI, ACPI: provide MCFG address for PCI host bridges Jiang Liu
2012-05-23  3:50 ` [PATCH v6 7/9] PCI, x86: update MMCFG information when hot-plugging " Jiang Liu
2012-05-23  3:50 ` [PATCH v6 8/9] PCI, x86: add MMCFG information on demand Jiang Liu
2012-05-23  3:50 ` [PATCH v6 9/9] PCI, x86: simplify pci_mmcfg_late_insert_resources() Jiang Liu
2012-05-24 18:26 ` [PATCH v6 0/9] PCI, x86: update MMCFG information when hot-plugging PCI host bridges Bjorn Helgaas
2012-05-24 23:09   ` Bjorn Helgaas
2012-05-25  2:21   ` Jiang Liu [this message]
2012-05-25 10:22 ` Taku Izumi
2012-05-25 14:43   ` Jiang Liu

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=4FBEECC0.5040108@huawei.com \
    --to=jiang.liu@huawei.com \
    --cc=bhelgaas@google.com \
    --cc=chenkeping@huawei.com \
    --cc=ddutile@redhat.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=kaneshige.kenji@jp.fujitsu.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=liuj97@gmail.com \
    --cc=wangyijing@huawei.com \
    --cc=yinghai@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).