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

[Stefan Bader <stefan.bader@canonical.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1533 bytes --]

On 15.02.2013 17:40, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 15, 2013 at 02:52:41PM +0000, Jan Beulich wrote:
>>>>> On 15.02.13 at 14:47, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>>>>>> 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 would be wrong even on native, and I don't see how that
>> would happen: memblock_add() gets called from
>> memblock_x86_fill() only for E820_RAM and E820_RESERVED_KERN
>> ranges.
> 
> Hm, the bug report shows that the ranges (which are E820_UNUSABLE)
> do get called with init_memory_mapping.
> 
Not sure it makes the difference but keep in mind that the report is about a 3.2
kernel. They initially claimed that 3.5 works, but then some comments seem to
say that was when using dom0_mem= which would in that case work around the bug.
Maybe time to go back and ask whether a recent kernel without dom0_mem on the
same machine still crashes...



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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