linux-kernel - Re: 2.6.25-rc1 xen pvops regression

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]

Message-Id: <1203665106.28436.19.camel@cthulhu.hellion.org.uk>
Date:	Fri, 22 Feb 2008 07:25:06 +0000
From:	Ian Campbell <ijc@...lion.org.uk>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Joel Becker <Joel.Becker@...cle.com>,
	Jody Belka <lists-lkml@...b.org>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andi Kleen <andi@...stfloor.org>,
	Mika Penttila <mika.penttila@...umbus.fi>
Subject: Re: 2.6.25-rc1 xen pvops regression


On Thu, 2008-02-21 at 14:58 -0800, H. Peter Anvin wrote:
> 
> Which it is on real hardware, because although it's not *reserved*
> (type 2), it is certainly not made available as *normal memory* (type
> 1).  If Xen maps this as type 1 then I definitely see the problem.
> 
> We can exclude type 1 memory from DMI scan, certainly.

I'd been meaning to ask this. So the machines you have which don't
describe 0xf0000 as reserved also don't describe it as RAM? (I guess
it's either a hole in the table or one of the other e820 types).

So it sounds like it would be acceptable to simply invert the test in my
original patch as below? (actually reverting to my original-original
patch which I never sent out because checking for reserved sounded more
correct at the time, which was dumb of me because I was well aware of
the other possible types, I must have been having one of those days).

Ian.

>>From 13bdb4ee9d80b83a81c3dbefa52464e511d1b4df Mon Sep 17 00:00:00 2001
From: Ian Campbell <ijc@...lion.org.uk>
Date: Fri, 22 Feb 2008 07:17:14 +0000
Subject: [PATCH] x86: Do not scan for DMI if the DMI region is marked as RAM by e820.

Under Xen the memory at 0xf0000 is regular RAM and so can potentially contain a
page table and hence cannot be mapped. The e820 map given to guest reflects
this.

Signed-off-by: Ian Campbell <ijc@...lion.org.uk>
---
 drivers/firmware/dmi_scan.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 653265a..f8fde74 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -7,6 +7,7 @@
 #include <linux/bootmem.h>
 #include <linux/slab.h>
 #include <asm/dmi.h>
+#include <asm/e820.h>
 
 static char dmi_empty_string[] = "        ";
 
@@ -371,6 +372,9 @@ void __init dmi_scan_machine(void)
 		}
 	}
 	else {
+		if (e820_all_mapped(0xF0000, 0xF0000+0x10000, E820_RAM))
+			goto out;
+
 		/*
 		 * no iounmap() for that ioremap(); it would be a no-op, but
 		 * it's so early in setup that sucker gets confused into doing
-- 
1.5.4.2



-- 
Ian Campbell

Stupidity, like virtue, is its own reward.

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