Re: [PATCH 1/3] x86, mm: Include the entire kernel memory mapin trampoline_pgd

[Jan Beulich]

>>> On 03.10.12 at 16:03, Matt Fleming <matt.fleming@xxxxxxxxx> wrote:
> On Wed, 2012-10-03 at 14:31 +0100, Jan Beulich wrote:
>> >>> Matt Fleming <matt@xxxxxxxxxxxxxxxxx> 10/03/12 2:59 PM >>>
>> >@@ -163,6 +258,10 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
>> >    ret_addr = (void __iomem *) (vaddr + offset);
>> >    mmiotrace_ioremap(unaligned_phys_addr, unaligned_size, ret_addr);
>>  >
>> >+    if (insert_identity_mapping(phys_addr, vaddr, size))
>> >+        printk(KERN_WARNING "ioremap: unable to map 0x%llx in identity pagetable\n",
>> >+                    (unsigned long long)phys_addr);
>> 
>> Isn't that going to trigger quite frequently on 32-bit kernels?
> 
> Hmmm... yeah, probably, though it didn't during my testing. If it is

That's suspicious, isn't it? In general, on any machine with more
than 3Gb of memory below the 4Gb boundary this ought to
trigger for _all_ mappings of MMIO space, and that's already only
considering the default of VMSPLIT_3G.

> likely to trigger a lot then we might be best only inserting the
> identity mmio mapping for 64-bit, and addressing the 32-bit case if we
> ever actually need the identity pagetable.

I think that would be the best choice for the moment.

Btw., once this set of yours is in - will I need to resubmit the
time handling patch that actually triggered this work, or will
you just reinstate it without further action on my part?

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/