lkml.org 
[lkml]   [2008]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.25-rc1 xen pvops regression
H. Peter Anvin wrote:
> Ian Campbell wrote:
>> On Thu, 2008-02-21 at 13:37 -0800, Jeremy Fitzhardinge wrote:
>>> H. Peter Anvin wrote:
>>>>> Still curious about why a pagetable page is ending up in that
>>>>> range though. Seems like it shouldn't be possible, since we
>>>>> shouldn't be allowed to allocate from those pages, at least until
>>>>> the DMI probe has happened... Unless the early allocator is only
>>>>> excluded from e820 reserved pages, which would cause a problem on
>>>>> systems which don't reserve the DMI space... HPA?
>>>>>
>>>> I thought the problem was a Xen-provided pagetable from before
>>>> Linux started?
>>> Hm, I don't think so. The domain-builder pagetable is put after the
>>> kernel, so it shouldn't be under 1M.
>>
>> I can confirm that it is Linux which is allocating it. The call path:
>> # xm create -c debian-x86_32p-1
>> Using config file "/etc/xen/debian-x86_32p-1".
>> Started domain debian-1
>> xen_alloc_pt_init PFN f0
>> Pid: 0, comm: swapper Not tainted 2.6.25-rc2 #68
>> [<c02ecb6b>] xen_alloc_pt_init+0x4b/0x60
>> [<c02f5e2b>] one_page_table_init+0x8b/0xf0
>> [<c02f63df>] paging_init+0x3bf/0x520
>> [<c02ee444>] setup_arch+0x2a4/0x410
>> [<c02e9a64>] start_kernel+0x64/0x380
>> [<c02efd7f>] cpu_detect+0x6f/0xf0
>> [<c02ed1a1>] xen_start_kernel+0x2f1/0x310
>> =======================
>> Entering add_active_range(0, 0, 262144) 0 entries of 256 used
>> Zone PFN ranges:
>> DMA 0 -> 4096
>>
>
> What is the e820 information you feed the kernel? We should only ever
> allocate page tables out of available RAM, not any other type of
> memory (reserved or not).

The kernel gets a flat memory map; all memory is just plain RAM. The
problem is that we're allocating a normal page and turning it into a
pagetable - so far so good. Then the DMI code is randomly mapping that
same page RW so it can scan it for DMI signatures, which Xen is preventing.

There are two immediate fixes:

1. Only scan for DMI if the memory is reserved (rejected, because HPA
says some machines don't reserve the DMI space). Alternatively,
don't bother scanning if booting under Xen.
2. Make DMI map the memory RO so that Xen doesn't complain (which is
sensible because DMI is ROM anyway).

But as far as I can tell, this shouldn't be happening anyway, and could
happen on real hardware which doesn't reserve the DMI space. It
probably doesn't because initial pagetables on real hardware use large
pages, and therefore allocate less memory for pagetable memory and
therefore doesn't end up hitting the 0xf0000 region. But that area
should be excluded from the allocation pool.

J


\
 
 \ /
  Last update: 2008-02-21 23:55    [W:0.133 / U:1.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site