lkml.org 
[lkml]   [2008]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    SubjectRe: 2.6.25-rc1 xen pvops regression
    From
    Date
    On Fri, 2008-02-22 at 07:25 +0000, Ian Campbell wrote:
    > 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).
    > Ian.

    ...

    > >From 13bdb4ee9d80b83a81c3dbefa52464e511d1b4df Mon Sep 17 00:00:00 2001
    > From: Ian Campbell <ijc@hellion.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@hellion.org.uk>

    ...

    > @@ -371,6 +372,9 @@ void __init dmi_scan_machine(void)
    > }
    > }
    > else {
    > + if (e820_all_mapped(0xF0000, 0xF0000+0x10000, E820_RAM))
    > + goto out;

    One issue with using the e820 map for this is that a Xen Dom0 will also
    have this region marked as RAM in the e820 map, but will set up a fixmap
    for it, allowing dmi_scan_machine() to map the region.

    Cheers,
    Mark.



    \
     
     \ /
      Last update: 2008-02-26 18:11    [W:3.721 / U:0.104 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site