On Thu, 2012-10-04 at 07:32 +0100, Jan Beulich wrote: > >>> 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. I don't know about it being suspicious - I don't have any x86 machines here with gigabytes of memory. But your point is still valid. > > 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. OK, cool. > 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? It's up to you. If you don't want to make any changes to your original patch then I'll just re-apply it on top of this series, updating the commit log to note why it got reverted and why it's now OK to re-apply. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
