[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170314194720.GD26264@bhelgaas-glaptop.roam.corp.google.com>
Date: Tue, 14 Mar 2017 14:47:20 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Andi Kleen <ak@...ux.intel.com>, Andi Kleen <andi@...stfloor.org>,
bhelgaas@...gle.com, x86@...nel.org, linux-pci@...r.kernel.org,
eranian@...gle.com, Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/4] x86, pci: Add interface to force mmconfig
On Tue, Mar 14, 2017 at 06:56:26PM +0100, Thomas Gleixner wrote:
> On Tue, 14 Mar 2017, Andi Kleen wrote:
> > The other option is to simply make it unconditional. That would
> > be even simpler, but it is a bit more risky. Hmm, I suppose may
> > be worth trying to find out what Windows uses. If they get away
> > with MMCONFIG everywhere we should be too.
>
> From the PCIe spec:
>
> The PCI 3.0 compatible Configuration Space can be accessed using either
> the mechanism defined in the PCI Local Bus Specification or the PCI
> Express Enhanced Configuration Access Mechanism (ECAM) described later in
> this section. Accesses made using either access mechanism are
> equivalent. The PCI Express Extended Configuration Space can only be
> accessed by using the ECAM.
>
> The 1.0 spec has a similar wording (s/3.0/2.3).
>
> Definitely the best way to go.
I agree that it should be fairly safe to do ECAM/MMCONFIG without
locking. Can we handle the decision part by adding a "lockless" bit
to struct pci_ops? Old ops don't mention that bit, so it will be
initialized to zero and we'll do locking as today. ECAM/MMCONFIG ops
can set it and we can skip the locking.
Bjorn
Powered by blists - more mailing lists