linux-kernel - Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is used

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 13 Sep 2007 21:52:03 +0200
From:	"Andreas Herrmann" <andreas.herrmann3@....com>
To:	"Andi Kleen" <ak@...e.de>
cc:	"Greg KH" <greg@...ah.com>, "Yinghai Lu" <Yinghai.Lu@....com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Jeff Garzik" <jeff@...zik.org>, "Martin Mares" <mj@....cz>,
	"dean gaudet" <dean@...tic.org>,
	"Robert Richter" <robert.richter@....com>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86_64: set cfg_size for AMD Family 10h in case
 MMCONFIG is used

On Thu, Sep 13, 2007 at 01:53:15PM +0200, Andi Kleen wrote:
> On Thursday 13 September 2007 12:47, Greg KH wrote:
> > On Thu, Sep 13, 2007 at 11:47:42AM +0200, Andi Kleen wrote:
> > > On Thursday 13 September 2007 04:21, Yinghai Lu wrote:
> > > > [PATCH] x86_64: set cfg_size for AMD Family 10h in case MMCONFIG is
> > > > used.
> > > >
> > > > reuse pci_cfg_space_size but skip check pci express and pci-x CAP ID.
> > >
> > > I just rejected a similar patch -- this should be done using MMCONFIG
> >
> > But what about for broken machines without the proper MMCONFIG entries?
> > They still need a way to get access to this config space,
> 
> If there are any devices that need it. IBS and PCI-E error handling 
> do, but they're quite obscure.
> 
> Also so far we don't know of any Fam 10h systems without MMCONFIG
> entries. Fam10h requires a new BIOS so it's reasonable to assume
> that the new BIOSes will do better.

IMHO support for all config space access methods should be added to the kernel.
And it should be added at a central point. Not waiting for drivers to do it
their own way if they need to use it.

The more complicated/important question is how to decide which access method
should be used for a device. (Something similar to the pci_mmcfg_fallback_slots
stuff that exists already for K8 NB.)
But that needs some more thinking.

Here a summary wrt family 10h extended config space access methods.
(Most of this stuff I verified with some patched kernels. I didn't
eavesdropping on the physical links though ...)

For family 10h we have 3 methods
(1) "legacy" MMCONFIG access (via south bridge)
(2) mmconfig access via CPU/NB (new with fam10h, using the new MMIO
    config base MSR)
(3) CF8/CFC ECS access (new with fam10h, has to be enabled in the NB_CFG MSR)

- If (1) is used  and (2)+(3) are not configurred there is no way to access
  NB config space with mmconfig accesses. Which implies that NB ECS cannot
  be accessed.
  So you can only access NB standard config space via "legacy" CF8/CFC.
  This equals what we have with K8.
  => ECS is accessible just for external devices (not the NB ECS).

- If (2) is used, mmconfig accesses are translated by CPU/NB. So this will
  result in (extended) config cycles on the link to the south bridge.
  This works for both NB config space and config space for normal PCI(e) devices.
  => ECS is accessible for all devices via that method.

- And finally with (3) you can also access both NB config space and the config
  space of external devices. The CPU/NB does the translation and will also
  create (extended) config cycles here.
  => ECS is accessible for all devices via that method.
  (But of course not in the same "atomic" manner like with mmconfig.)

Then we have different prereqs for those methods:
- For (1) the ACPI stuff is required.
- For (2) and (3) some MSRs have to be set up.

Ah, yes in case I didn't mention that: ;-)
Using (2) you haven't such a strict dependency on that ACPI stuff.
Would be cool to disable MCFG at all and configure mmconfig just in
the CPU, no?


Regards,

Andreas

-- 
Operating | AMD Saxony Limited Liability Company & Co. KG,
  System  | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 Research | Register Court Dresden: HRA 4896, General Partner authorized
  Center  | to represent: AMD Saxony LLC (Wilmington, Delaware, US)
  (OSRC)  | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy



-
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/