K8 Errata #93: adjusting address to a fixup block

K8 Errata #93: adjusting address to a fixup block

[Alexandre Oliva]

[-- Attachment #1: Type: text/plain, Size: 476 bytes --]

While I investigated the problem of probing the touchpad on a Compaq
Presario r3004, I'd sometimes get the K8 Errata #93 warning.  One of
my theories was that we might be missing some fix up because of the
Errata, or adjusting an address that wasn't the current-instruction
address, so I came up with this patch.  It turned out to make no
difference, but it still feels like an improvement to me, since some
day we might be resuming from halt into a fix-up block.  Thoughts?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: linux-2.6.9-k8errata93.patch --]
[-- Type: text/x-patch, Size: 1245 bytes --]

--- arch/x86_64/mm/fault.c.k8errata93	2004-10-17 08:49:45.000000000 -0300
+++ arch/x86_64/mm/fault.c	2004-10-17 11:14:40.000000000 -0300
@@ -188,9 +188,12 @@
    Try to work around it here.
    Note we only handle faults in kernel here. */
 
-static int is_errata93(struct pt_regs *regs, unsigned long address) 
+static int is_errata93(struct pt_regs *regs, unsigned long address,
+		       unsigned long error_code)
 {
 	static int warned;
+	if ((error_code & 16) == 0)
+		return 0;
 	if (address != regs->rip)
 		return 0;
 	if ((address >> 32) != 0) 
@@ -202,6 +205,8 @@
 			printk(errata93_warning); 		
 			warned = 1;
 		}
+		printk(KERN_DEBUG "is_errata93 adjusted %lx to %lx\n",
+		       regs->rip, address);
 		regs->rip = address;
 		return 1;
 	}
@@ -253,6 +258,7 @@
 	const struct exception_table_entry *fixup;
 	int write;
 	siginfo_t info;
+	int errata93_return = 0;
 
 #ifdef CONFIG_CHECKING
 	{ 
@@ -463,8 +469,11 @@
  	if (is_prefetch(regs, address, error_code))
  		return;
 
-	if (is_errata93(regs, address))
-		return; 
+	if (is_errata93(regs, address, error_code)) {
+		errata93_return = 1;
+		goto no_context;
+	} else if (errata93_return)
+		return;
 
 /*
  * Oops. The kernel tried to access some bad page. We'll have to

[-- Attachment #3: Type: text/plain, Size: 188 bytes --]


-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: K8 Errata #93: adjusting address to a fixup block

[Andi Kleen]

Alexandre Oliva <aoliva@redhat.com> writes:

> While I investigated the problem of probing the touchpad on a Compaq
> Presario r3004, I'd sometimes get the K8 Errata #93 warning.  One of
> my theories was that we might be missing some fix up because of the
> Errata, or adjusting an address that wasn't the current-instruction

It's more likely the BIOS is executing SMM code to handle
the touch pad and that SMM code doesn't have the correct
workaround for the erratum.

> address, so I came up with this patch.  It turned out to make no
> difference, but it still feels like an improvement to me, since some
> day we might be resuming from halt into a fix-up block.  Thoughts?

The code is already ugly enough and handles most of the cases, 
I don't think it is worth it complicating it even more just
to handle more corner cases of buggy BIOS.

The real fix is to fix your BIOS.

 	static int warned;
+	if ((error_code & 16) == 0)
+		return 0;

This is dubious because the I/D bit is undefined when NX is disabled
in EFER (e.g. with noexec=off or when the CPU doesn't support NX)

-Andi

Re: K8 Errata #93: adjusting address to a fixup block

[Alexandre Oliva]

On Oct 17, 2004, Andi Kleen <ak@muc.de> wrote:

>> address, so I came up with this patch.  It turned out to make no
>> difference, but it still feels like an improvement to me, since some
>> day we might be resuming from halt into a fix-up block.  Thoughts?

> The code is already ugly enough and handles most of the cases, 
> I don't think it is worth it complicating it even more just
> to handle more corner cases of buggy BIOS.

Fair enough.

> The real fix is to fix your BIOS.

>  	static int warned;
> +	if ((error_code & 16) == 0)
> +		return 0;

> This is dubious because the I/D bit is undefined when NX is disabled
> in EFER (e.g. with noexec=off or when the CPU doesn't support NX)

Aah...  I wasn't aware of that.  Patch withdrawn for sure, then :-)
Thanks for the feedback.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}