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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 3 Sep 2007 10:32:42 +0200
From:	"Andreas Herrmann" <andreas.herrmann3@....com>
To:	"Andi Kleen" <ak@...e.de>
cc:	"Robert Richter" <robert.richter@....com>, patches@...-64.org,
	linux-kernel@...r.kernel.org
Subject: Re: [patches] [patch 3/5] x86: Add PCI extended config space
 access for AMD Barcelona

On Sat, Sep 01, 2007 at 12:11:52PM +0200, Andi Kleen wrote:
> On Thursday 30 August 2007 19:43:14 Robert Richter wrote:
> > This patch implements PCI extended configuration space access for
> > AMD's Barcelona CPUs. It extends the method using CF8/CFC IO
> > addresses. An x86 capability bit has been introduced that is set for
> > CPUs supporting PCI extended config space accesses.
> 
> We shouldn't need this because extended config space should work
> here and Linux should use it 
> (especially after we added the ugly Barcelona workaround into  that code) 

This patch is needed for all buggy BIOSes that don't correctly set up MCFG.

> The only exception would be if the user disables MMCONFIG in CONFIG, but that's
> their own fault then.

No, as you stated yourself there are two exceptions. And the more serious one is the
BIOS issue.

> Ok there might be buggy BIOS around with no or no usable MCFG table, but since
> extended config space is not really a critical feature that's not a big issue.

Not sure why you assume extended config space (ECS) is not critical.
Ok, for a lot of stuff it does not matter.
But it is needed for some devices for full functionality.
E.g. for perfmon (family 0x10/extended inerrupts) extended config space access
is a prerequisite.

> So I don't think we want this special case code at all and should
> just rely on MMCONFIG.

Rely on something unreliable (due to buggy/incomplete BIOS)?
I don't think we should do this.

IMHO it is best to try to use MMCONFIG if it's working and to use
a fallback (e.g. CF8 ECS access for family 0x10) if available.


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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ