[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140430070042.GN32718@rric.localhost>
Date: Wed, 30 Apr 2014 09:00:42 +0200
From: Robert Richter <rric@...nel.org>
To: Myron Stowe <myron.stowe@...il.com>
Cc: Borislav Petkov <bp@...en8.de>,
Suravee Suthikulanit <suravee.suthikulpanit@....com>,
Borislav Petkov <bp@...e.de>,
Andreas Herrmann <herrmann.der.user@...glemail.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Myron Stowe <myron.stowe@...hat.com>,
Aravind Gopalakrishnan <aravind.gopalakrishnan@....com>,
linux-pci <linux-pci@...r.kernel.org>, kim.naru@....com,
Daniel J Blueman <daniel@...ascale.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, x86 <x86@...nel.org>,
Steffen Persvold <sp@...ascale.com>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Jan Beulich <JBeulich@...e.com>,
Yinghai Lu <yinghai@...nel.org>
Subject: Re: [PATCH v2 2/5] x86/PCI: Support additional MMIO range
capabilities
On 29.04.14 15:40:28, Myron Stowe wrote:
> On Tue, Apr 29, 2014 at 1:14 PM, Borislav Petkov <bp@...en8.de> wrote:
> > So sounds to me like we want to get rid of the whole IO ECS deal
> > altogether then.
> >
> > Now, I'm wondering whether we should kill it completely since I don't
> > think anyone cares about numa node info being correct on K8, or? I'm
> > specifically turning to our numascale friends who love to have a lot of
> > nodes. :-)
Maybe I did get you wrong, but IO ECS was introduced with fam10h and
is not related to k8.
> I think we need to be careful here as there are two unrelated topics
> being discussed together. What started this whole thread was the need
> for sysfs related numa_node information with respect to PCI devices
> (1). Without patch 1, platforms with newer AMD CPUs end up having
> '-1' numa_node values for all PCI devices.
>
> IO ECS has no bearing on patch 1, it only comes into play with patch 2
> which is concerned with MMIO resource information when MCFG doesn't
> exist. For the particular issue I'm trying to get resolved, patch 2
> is not needed. However, since we have expended time and effort on
> this subject, perhaps we should get this cleaned up while it has our
> attention.
>
> I'm all for deleting as much of amd_bus.c as possible due to its
> "perennial maintenance headache". The obvious choices seem to be all,
> or some combination, of:
> o removing IO ECS logic,
> o removing IO/MMIO logic (assuming MCFG issues were long enough ago
> to no longer be a concern),
> o start deprecating amd_bus.c by adding logic to skip if BIOS >= 2015
I don't see any reason for big changes actually. Just bind the IO ECS
logic to fam10h (either with fam check or pci device depending on the
implementation, xen's flavor would be pci). This is something stricter
than 'if BIOS >= 2015'. It leaves code as it is which is maintainable.
You implement the new logic for for newer families. No need for one
implementation that fits all.
-Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists