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]

Date:	Mon, 18 Feb 2008 02:40:25 -0800
From:	Joel Becker <Joel.Becker@...cle.com>
To:	Ian Campbell <ijc@...lion.org.uk>
Cc:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Jody Belka <lists-lkml@...b.org>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	"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 Sun, Feb 17, 2008 at 06:49:21PM +0000, Ian Campbell wrote:
> I've been seeing similar attempts to map 0xf0 but so far I was the only
> one (although that made no sense to me). Does the patch below help at
> all? The problem seems to be that the kernel is trying to map pages at
> 0xf0000 but these are not reserved in the guest E820 map so they could
> contain a page table page etc.
> 
> A useful tip for getting a backtrace out of a crashed Xen guest is to
> set "on_crash=preserve" in your domain config. Then once the crash has
> happened you can use "/usr/lib/xen/bin/xenctx -s System.map <domid>"
> where System.map is the guest kernel System.map.

	That didn't work for me - it gave me "can't trace dom0" for
whatever reason.  But...

> x86/xen: Do not scan for DMI unless the DMI region is reserved by e820.
> 
> Signed-off-by: Ian Campbell <ijc@...lion.org.uk>
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index 9008ed5..79525f5 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[] = "        ";
>  
> @@ -336,6 +337,10 @@ void __init dmi_scan_machine(void)
>  		}
>  	}
>  	else {
> +
> +		if (!e820_all_mapped(0xF0000, 0xF0000+0x10000, E820_RESERVED))
> +			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

	This fixed it.  I'm now booting successfully.  Thank you!  If
you have any furthur patches you'd like to test, I'd be happy to do so.

Joel

-- 

"And yet I find,
 And yet I find repeating in my head.
 If I can't be my own, 
 I'd feel better dead."

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@...cle.com
Phone: (650) 506-8127
--
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/