linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiang Liu <liuj97@gmail.com>
To: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>,
	Yinghai Lu <yinghai@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Jiang Liu <jiang.liu@huawei.com>,
	Keping Chen <chenkeping@huawei.com>,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH 2/2] PCI, ACPI, x86: update MMCFG information when hot-plugging PCI host bridges
Date: Wed, 11 Apr 2012 00:01:49 +0800	[thread overview]
Message-ID: <4F84596D.9010606@gmail.com> (raw)
In-Reply-To: <4F840C3C.2060302@jp.fujitsu.com>

On 04/10/2012 06:32 PM, Kenji Kaneshige wrote:
> (2012/04/10 1:02), Jiang Liu wrote:
>> Hi Kenji,
>>     Thanks for your careful review and comments.
>>
>> On 04/09/2012 07:43 PM, Kenji Kaneshige wrote:
>>> Your patch looks good to me.
>>>
>>> I have some comments.
>>>
>>> (2012/04/09 2:12), Jiang Liu wrote:
>>>> This patch enhances pci_root driver to update MMCFG information when
>>>> hot-plugging PCI root bridges on x86 platforms.
>>>>
>>>
>>> Do you have the patch that can be applied to Bjorn's pci tree?
>>>
>>> <snip.>
>> Will try to generate a version against Bjorn's version. Could you please tell
>> me the exact git link for that? I haven't pull from Bjorn's tree yet.
> 
> As you may know, it was announced _today_ (sorry:).
> 
> http://www.spinics.net/lists/linux-pci/msg14626.html
> 
>>
>>>
>>>> +int arch_acpi_pci_root_add(struct acpi_pci_root *root)
>>>> +{
>>>> +    int result = 0;
>>>> +    acpi_status status;
>>>> +    unsigned long long base_addr;
>>>> +    struct pci_mmcfg_region *cfg;
>>>> +
>>>> +    /*
>>>> +     * Try to insert MMCFG information for host bridges with _CBA method
>>>> +     */
>>>> +    status = acpi_evaluate_integer(root->device->handle, METHOD_NAME__CBA,
>>>> +                       NULL,&base_addr);
>>>> +    if (ACPI_SUCCESS(status)) {
>>>> +        result = pci_mmconfig_insert(root->segment,
>>>> +                         root->secondary.start,
>>>> +                         root->secondary.end,
>>>> +                         base_addr);
>>>> +        /*
>>>> +         * MMCFG information for hot-pluggable host bridges may have
>>>> +         * already been added by __pci_mmcfg_init();
>>>> +         */
>>>> +        if (result == -EEXIST)
>>>> +            result = 0;
>>>
>>> Just for confirmation.
>>>  From my interpretation of PCI firmware spec, MCFG doesn't have any entry
>>> for hot-pluggable hostbridge. So I assume this is for the machine that
>>> is not compliant to the spec. Is my understanding same as yours?
>>>
>>> <snip.>
>> You are right, it's defined to that way in PCI FW Spec 3.1.
>> Here I have some concerns about the PCI buses to host all Ubox components
>> on Intel NHM/WSM/SNB/IVB processors. BIOS people are prone to declare
>> MMCFG information for those host bridges by MCFG table instead of _CBA method,
>> though those host bridge will disappear after hot-removing a physical processor.
> 
> Ok, thank you for clarification.
> 
>>
>>>
>>>>    static int __devinit acpi_pci_root_add(struct acpi_device *device)
>>>>    {
>>>>        unsigned long long segment, bus;
>>>> @@ -504,6 +514,14 @@ static int __devinit acpi_pci_root_add(struct acpi_device *device)
>>>>        strcpy(acpi_device_class(device), ACPI_PCI_ROOT_CLASS);
>>>>        device->driver_data = root;
>>>>
>>>> +    if (arch_acpi_pci_root_add(root)) {
>>>> +        printk(KERN_ERR PREFIX
>>>> +            "can't add MMCFG information for Bus %04x:%02x\n",
>>>> +            root->segment, (unsigned int)root->secondary.start);
> 
> Additional comment.
> 
> This printk message looks strange because arch_acpi_pci_root_add()
> is not a mmconfig specific function. So I think this message
> should be moved to arch specific code (arch_acpi_pci_root_add()).
> 
>>>> +        result = -ENODEV;
>>>> +        goto out_free;
>>>> +    }
>>>
>>> Desn't this break the system that doesn't support MMCONFIG?
>>>
>>> In my understanding, arch_acpi_pci_root_add() returns -ENODEV if
>>> mmconfig information is found neither in MCFG table nor _CBA. And
>>> pci root bridge initialization seems to fail arch_acpi_pci_root_add()
>>> returns non-zero value.
>> Good catch, will add following code into arch_acpi_pci_root_add() and
>> arch_acpi_pci_root_remove() to solve this issue.
>> ---
>>          /* MMCONFIG disabled */
>>          if ((pci_probe&  PCI_PROBE_MMCONF) == 0)
>>                  return 0;
>> ---
> 
> My understanding is that PCI_PROBE_MMCONF is set even if the system
> doesn't have MCFG table. So I don't think this solves the issue. I
> guess this is what Yinghai pointed out on your V2 patch [6/6].
> 
> Additionally, I think there is a remaining issue even if we change
> this check like below.
> 
>     if (!!(pci_probe & PCI_PROBE_MASK & ~PCI_PROBE_MMCONF))
>             return 0;
> 
> I think this check has an assumption that system has at least one
> MCFG table entry and it has been initialized before
> acpi_pci_root_add() is called. I think this doesn't work on the
> system that doesn't have MCFG and all the pci root bridge have
> _CBA (that is, all host bridges are hot-pluggable and BIOS is
> implemented in the way PCI FW spec defines). As a result, MMCONFIG
> would never be enabled on such systems. Could you double check this?
Good points. We underestimated the complexity here.
I'm working on a new patch based on Yinghai's v3 patchset and will send
it out soon.
Thanks!

> 
> Regards,
> Kenji Kaneshige


  parent reply	other threads:[~2012-04-10 16:01 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-06  2:59 [PATCH] [RFC] PCI, ACPI, x86: MMCFG support for hotpluggable PCI hostbridges on x86, x86_64 Taku Izumi
2012-04-06  6:31 ` Kenji Kaneshige
2012-04-06 11:15   ` Taku Izumi
2012-04-06 11:16   ` Taku Izumi
2012-04-07 15:20     ` Jiang Liu
2012-04-25 17:14       ` Bjorn Helgaas
2012-04-26  2:55         ` Taku Izumi
2012-04-07 15:09   ` Jiang Liu
2012-04-08 17:12 ` [PATCH RFC 0/2] PCI, x86: update MMCFG information when hot-plugging PCI host bridges Jiang Liu
2012-04-25 17:17   ` Bjorn Helgaas
2012-04-08 17:12 ` [PATCH 1/2] PCI,x86: introduce new MMCFG interfaces to support PCI host bridge hotplug Jiang Liu
2012-04-08 19:12   ` Yinghai Lu
2012-04-08 17:12 ` [PATCH 2/2] PCI, ACPI, x86: update MMCFG information when hot-plugging PCI host bridges Jiang Liu
2012-04-08 19:19   ` Yinghai Lu
2012-04-09  3:43     ` Jiang Liu
2012-04-09 14:37     ` Jiang Liu
2012-04-09 15:11       ` Yinghai Lu
2012-04-09 20:48       ` Yinghai Lu
2012-04-09 11:43   ` Kenji Kaneshige
2012-04-09 16:02     ` Jiang Liu
2012-04-10 10:32       ` Kenji Kaneshige
2012-04-10 15:47         ` Yinghai Lu
2012-04-10 16:05           ` Jiang Liu
2012-04-10 16:01         ` Jiang Liu [this message]
2012-05-02 23:55   ` Bjorn Helgaas
2012-05-03  6:39     ` 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=4F84596D.9010606@gmail.com \
    --to=liuj97@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=chenkeping@huawei.com \
    --cc=izumi.taku@jp.fujitsu.com \
    --cc=jiang.liu@huawei.com \
    --cc=kaneshige.kenji@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --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).