[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 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@xxxxxxxxxx> 
>>>>> 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: signature.asc
Description: OpenPGP digital signature

_______________________________________________
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®.