From: Robert Richter <rric@kernel.org>
To: Andreas Herrmann <herrmann.der.user@googlemail.com>
Cc: Borislav Petkov <bp@suse.de>, Bjorn Helgaas <bhelgaas@google.com>,
herrmann.der.user@gmail.com, Myron Stowe <myron.stowe@gmail.com>,
Myron Stowe <myron.stowe@redhat.com>,
linux-pci <linux-pci@vger.kernel.org>,
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>,
kim.naru@amd.com, Daniel J Blueman <daniel@numascale.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86 <x86@kernel.org>, Steffen Persvold <sp@numascale.com>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Jan Beulich <JBeulich@suse.com>, Yinghai Lu <yinghai@kernel.org>
Subject: Re: [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities
Date: Tue, 29 Apr 2014 13:19:19 +0200 [thread overview]
Message-ID: <20140429111919.GI32718@rric.localhost> (raw)
In-Reply-To: <20140429073309.GE10997@alberich>
On 29.04.14 09:33:09, Andreas Herrmann wrote:
> On Mon, Apr 28, 2014 at 11:40:36PM +0200, Borislav Petkov wrote:
> > On Mon, Apr 28, 2014 at 02:50:29PM -0600, Bjorn Helgaas wrote:
> > > This I/O ECS thing seems likely to cause future problems. My
> > > understanding (based on sec 2.8 of [1]) is that enable_pci_io_ecs()
> > > and pci_enable_pci_io_ecs() are there to enable access to extended
> > > config space (offsets 256-4095) via the 0xcf8/0xcfc I/O ports.
> > >
> > > Per sec 4.1.1 of [2], we should be using ECAM (the memory-mapped
> > > enhanced configuration mechanism, i.e., MMCONFIG) to access extended
> > > config space, and the BIOS should supply an MCFG table.
This is due to the non-atomic access to 0xcf8/0xcfc.
IIRC, another problem with io cfg space access is that it is bound to
register rax or so. The kernel implementation may not change here.
Otherall mmconfig access is much better implemented and thus
recommended to use by the os, while io cfg is used mainly by the bios.
> > > So why do we need to enable I/O access to ECS on AMD chips at all? Is
> > > this a workaround for a broken BIOS that doesn't supply an MCFG table?
> >
> > That's a good question. 831d991821dae doesn't say but I have a hunch
> > Andreas and/or Robert should know. I seem to vaguely remember it
> > might've been because of a missing MCFG but have flushed it out of the
> > cache long time ago.
> >
> > Let's ask them.
> >
> > Andreas, Robert, guys, do you remember why we did the PCI IO ECS access?
> > B0rked BIOSes?
>
>
> I am sure, it's because some server systems had MMIO ECS access not
> enabled in BIOS. I can't remember which systems were affected.
Yes, mmio ecs was not enabled on some systems by the bios. We needed
to use cf8/cfc io access.
If MMCONFIG is available it is the default, cf8/cfc is only used
otherwise. Also, some kernel configs may disable MMCONFIG.
PCI ECS was especially needed to enable the IBS interrupt for hw
profiling.
-Robert
next prev parent reply other threads:[~2014-04-29 11:19 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-05 21:06 [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems suravee.suthikulpanit
2014-03-05 21:06 ` [PATCH 1/3] amd/pci: Add supports for generic AMD hostbridges suravee.suthikulpanit
2014-03-05 21:06 ` [PATCH 2/3] amd/pci: Support additional MMIO ranges capabilities suravee.suthikulpanit
2014-03-20 17:33 ` Bjorn Helgaas
2014-03-05 21:06 ` [PATCH 3/3] amd/pci: Miscellaneous code clean up for early_fillup_mp_bus_info suravee.suthikulpanit
2014-03-05 21:24 ` [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems Bjorn Helgaas
2014-03-06 2:13 ` Suravee Suthikulanit
2014-03-06 6:30 ` Suravee Suthikulpanit
2014-03-06 17:40 ` Bjorn Helgaas
2014-03-06 20:03 ` Suravee Suthikulpanit
2014-03-11 18:12 ` Bjorn Helgaas
2014-03-12 21:13 ` Bjorn Helgaas
2014-03-13 1:30 ` Myron Stowe
2014-03-14 2:06 ` Suravee Suthikulpanit
2014-03-17 17:18 ` Bjorn Helgaas
2014-03-20 17:42 ` Bjorn Helgaas
2014-04-19 2:53 ` [PATCH v2 0/5] x86/PCI: Add AMD hostbridge support " Myron Stowe
2014-04-19 2:53 ` [PATCH v2 1/5] x86/PCI: Add support for generic AMD hostbridges Myron Stowe
2014-04-19 11:31 ` Borislav Petkov
2014-04-28 21:10 ` Myron Stowe
2014-04-19 2:53 ` [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities Myron Stowe
2014-04-19 13:52 ` Borislav Petkov
2014-04-20 7:59 ` Borislav Petkov
2014-04-25 22:24 ` Myron Stowe
2014-04-26 9:10 ` Borislav Petkov
2014-04-28 20:50 ` Bjorn Helgaas
2014-04-28 21:40 ` Borislav Petkov
2014-04-29 7:33 ` Andreas Herrmann
2014-04-29 10:20 ` Borislav Petkov
2014-04-29 13:07 ` Steffen Persvold
2014-04-29 15:16 ` Suravee Suthikulanit
2014-04-29 19:14 ` Borislav Petkov
2014-04-29 21:40 ` Myron Stowe
2014-04-30 7:00 ` Robert Richter
2014-04-30 7:50 ` Suravee Suthikulpanit
2014-04-30 9:51 ` Robert Richter
2014-04-30 23:03 ` Myron Stowe
2014-04-29 11:19 ` Robert Richter [this message]
2014-04-29 7:06 ` Jan Beulich
2014-04-29 3:04 ` Suravee Suthikulanit
2014-04-28 21:19 ` Myron Stowe
2014-04-29 2:47 ` Suravee Suthikulanit
2014-04-29 17:17 ` Robert Richter
2014-04-30 6:41 ` Robert Richter
2014-04-19 2:53 ` [PATCH v2 3/5] x86/PCI: Miscellaneous code clean up for early_fillup_mp_bus_info Myron Stowe
2014-04-20 8:02 ` Borislav Petkov
2014-04-28 21:21 ` Myron Stowe
2014-04-19 2:53 ` [PATCH v2 4/5] ACPI/PCI: Warn if we have to "guess" host bridge node information Myron Stowe
2014-04-20 10:21 ` Borislav Petkov
2014-04-28 21:24 ` Myron Stowe
2014-04-29 19:16 ` Borislav Petkov
2014-04-19 2:53 ` [PATCH v2 5/5] PCI: Remove redundant 'quirk_amd_nb_node' Myron Stowe
2014-04-20 10:54 ` Borislav Petkov
2014-04-20 13:44 ` Myron Stowe
2014-04-21 16:53 ` Daniel J Blueman
2014-04-29 2:02 ` Suravee Suthikulanit
2014-04-29 19:29 ` Bjorn Helgaas
2014-04-28 21:28 ` Myron Stowe
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=20140429111919.GI32718@rric.localhost \
--to=rric@kernel.org \
--cc=JBeulich@suse.com \
--cc=aravind.gopalakrishnan@amd.com \
--cc=bhelgaas@google.com \
--cc=bp@suse.de \
--cc=daniel@numascale.com \
--cc=herrmann.der.user@gmail.com \
--cc=herrmann.der.user@googlemail.com \
--cc=hpa@zytor.com \
--cc=kim.naru@amd.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=myron.stowe@gmail.com \
--cc=myron.stowe@redhat.com \
--cc=sp@numascale.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=tglx@linutronix.de \
--cc=x86@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).