On Tue, Oct 23, 2012 at 10:05:01AM -0600, Randy Wright wrote:
> On the first: one way to be compliant with such a requirement would be
> to design systems that implement softfail in this particular region.
> What about a system that hardfails, but on which the resulting machine
> check can be
Hi Matthew,
You made some interesting suggestions:
> 1) Declare that any x86 hardware supported by Linux *must* support
> probing in this address region
On the first: one way to be compliant with such a requirement would be
to design systems that implement softfail in this particular region.
Hi Matthew,
You made some interesting suggestions:
1) Declare that any x86 hardware supported by Linux *must* support
probing in this address region
On the first: one way to be compliant with such a requirement would be
to design systems that implement softfail in this particular region.
On Tue, Oct 23, 2012 at 10:05:01AM -0600, Randy Wright wrote:
On the first: one way to be compliant with such a requirement would be
to design systems that implement softfail in this particular region.
What about a system that hardfails, but on which the resulting machine
check can be
On 10/19/2012 08:30 AM, Matthew Garrett wrote:
I don't think DMI checking is going to work, since (a) as you say,
there's a risk that the ID will inadvertantly change over the lifecycle
of the machine, and (b) there may be other machines. So if it's not
possible to handle this by catching the
I don't think DMI checking is going to work, since (a) as you say,
there's a risk that the ID will inadvertantly change over the lifecycle
of the machine, and (b) there may be other machines. So if it's not
possible to handle this by catching the MCE, I think we have two
options:
1) Declare
I would like to summarize progress I have made on this issue in the past
few days, and then appeal for help in evaluating the options. Matthew
and H. Peter Anvin, I would appreciate your additional input especially.
The general idea under consideration here is to avoid access to the
legacy
I would like to summarize progress I have made on this issue in the past
few days, and then appeal for help in evaluating the options. Matthew
and H. Peter Anvin, I would appreciate your additional input especially.
The general idea under consideration here is to avoid access to the
legacy
I don't think DMI checking is going to work, since (a) as you say,
there's a risk that the ID will inadvertantly change over the lifecycle
of the machine, and (b) there may be other machines. So if it's not
possible to handle this by catching the MCE, I think we have two
options:
1) Declare
On 10/19/2012 08:30 AM, Matthew Garrett wrote:
I don't think DMI checking is going to work, since (a) as you say,
there's a risk that the ID will inadvertantly change over the lifecycle
of the machine, and (b) there may be other machines. So if it's not
possible to handle this by catching the
> Date: Thu, 4 Oct 2012 20:22:56 +0100
> From: Matthew Garrett
> To: rwri...@hp.com
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: [PATCH RFC] function probe_roms accessing improper addresses
> on UEFI systems
> Message-ID: <20121004192256.ga6...@srcf.ucam.org>
Date: Thu, 4 Oct 2012 20:22:56 +0100
From: Matthew Garrett mj...@srcf.ucam.org
To: rwri...@hp.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC] function probe_roms accessing improper addresses
on UEFI systems
Message-ID: 20121004192256.ga6...@srcf.ucam.org
References
On Wed, Oct 03, 2012 at 05:53:46PM -0600, Randy Wright wrote:
> The following proposed patch takes advantage of the fact that on EFI
> systems, the memory map provides a better description of the physical
> space than on pre-EFI legacy systems. If the efi_enabled state variable
> indicates the
On Wed, Oct 03, 2012 at 05:53:46PM -0600, Randy Wright wrote:
The following proposed patch takes advantage of the fact that on EFI
systems, the memory map provides a better description of the physical
space than on pre-EFI legacy systems. If the efi_enabled state variable
indicates the kernel
The code in function probe_roms accesses the legacy adapter space (in
the physical address range 640k-1mb) without regard to how this range is
described in the memory map. The assumption in the code is that the
result of an access to unpopulated space is a soft fail, returning -1.
This assumption
The code in function probe_roms accesses the legacy adapter space (in
the physical address range 640k-1mb) without regard to how this range is
described in the memory map. The assumption in the code is that the
result of an access to unpopulated space is a soft fail, returning -1.
This assumption
16 matches
Mail list logo
