[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen/x86: Force removal of memory range when not covered by MTRRs



On Fri, Feb 15, 2013 at 11:13:52AM +0000, Jan Beulich wrote:
> >>> On 15.02.13 at 11:34, Stefan Bader <stefan.bader@xxxxxxxxxxxxx> wrote:
> > On 15.02.2013 10:19, Jan Beulich wrote:
> >>>>> On 14.02.13 at 18:11, Stefan Bader <stefan.bader@xxxxxxxxxxxxx> wrote:
> >>> On a machine that could not cover all its RAM with MTRR ranges,
> >>> a crash on boot as dom0 was caused by dom0 trying to create
> >>> kernel mapping tables for the clipped range.
> >>>
> >>> (XEN) WARNING: MTRRs do not cover all of memory.
> >>> (XEN) Truncating RAM from 9109504kB to 9043968kB
> >>> ...
> >>> (XEN)  0000000228000000 - 000000022c000000 (unusable)
> >>> ...
> >>> [    0.000000] init_memory_mapping: 0000000228000000-000000022c000000
> >>> [    0.000000]  0228000000 - 022c000000 page 4k
> >>> [    0.000000] kernel direct mapping tables up to 22c000000 @
> >>>                1e97d8000-1e97fa000
> >>> (XEN) mm.c:825:d0 Non-privileged (0) attempt to map I/O space 00228000
> >>> (XEN) mm.c:1222:d0 Failure in alloc_l1_table: entry 0
> >>> (XEN) mm.c:2177:d0 Error while validating mfn 81de (pfn 1e97d8) for
> >>>       type 1000000000000000: caf=8000000000000003 taf=1000000000000001
> >>> (XEN) mm.c:2985:d0 Error while pinning mfn 81de
> >>>
> >>> Setting the range in E820 to E280_UNUSABLE seems ambigous as
> >>> this is the same type that gets used for memory to be used only
> >>> as guest memory (using dom0_mem=).
> >> 
> >> Since when is E820_UNUSABLE memory being used as guest
> >> memory? If that's indeed the case, that's the bug to fix. The
> >> above data to me shows, however, that the range above
> >> 228000000 is considered invalid. So then the question is why the
> >> kernel tries to map that memory in the first place (the hypervisor
> >> rejecting the attempt, despite Dom0 being privileged, seems
> >> correct to me, as the range is also known not to be MMIO).

B/c it gets the E820 from the hypervisor, which shows that area as
E820_UNUSABLE. And dom0 (or rather, the generic memory code) ends up
creating pagetables for it.

> > 
> > That seems to be done for a while now... On my testbox, when using 
> > dom0_mem=:
> > 
> > (XEN)  00000000dfe9e000 - 00000000dfea0000 type 9
> > (XEN)  00000000dfea0000 - 00000000dfeb2000 (ACPI data)
> > (XEN)  00000000dfeb2000 - 00000000dfee0000 (ACPI NVS)
> > (XEN)  00000000dfee0000 - 00000000f0000000 (reserved)
> > (XEN)  00000000ffe00000 - 0000000100000000 (reserved)
> > (XEN)  0000000100000000 - 0000000820000000 (usable)
> 
> All that counts is what you see above.
> 
> > In dom0:
> > [    0.000000] Xen: [mem 0x00000000dfe9e000-0x00000000dfe9ffff] type 9
> > [    0.000000] Xen: [mem 0x00000000dfea0000-0x00000000dfeb1fff] ACPI data
> > [    0.000000] Xen: [mem 0x00000000dfeb2000-0x00000000dfedffff] ACPI NVS
> > [    0.000000] Xen: [mem 0x00000000dfee0000-0x00000000efffffff] reserved
> > [    0.000000] Xen: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
> > [    0.000000] Xen: [mem 0x00000000fec20000-0x00000000fec20fff] reserved
> > [    0.000000] Xen: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
> > [    0.000000] Xen: [mem 0x00000000ffe00000-0x00000000ffffffff] reserved
> > [    0.000000] Xen: [mem 0x0000000100000000-0x00000002e063ffff] usable
> > [    0.000000] Xen: [mem 0x00000002e0640000-0x000000081fffffff] unusable
> 
> What Dom0 does to its representation of the E820 map is of no
> concern to the hypervisor. So are we in agreement then that the
> hypervisor code is fine without any changes?

I am not clear on what the right fix is. Dom0 could interpret E820_UNUSABLE
as memory to be considered as E820_RESERVED - but then I am wondering what
to do with hotplug memory. As in, does the BIOS mark memory that can be 
hotplugged
as E820_RESERVED or E820_UNUSABLE? So if we mark the memory as E820_RESERVED
and the hotplug memory code expects that - will we confuse it as there are now
new ranges of it?

Perhaps dom0 should just eviscerate that range altogether. But then it will
be considered as MMIO region and that will lead to trouble with i915 at least.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.