Message-ID: <1349342304.15966.25.camel@mfleming-mobl1.ger.corp.intel.com>
Subject: Re: [PATCH 1/3] x86, mm: Include the entire kernel memory map in
 trampoline_pgd
From: Matt Fleming <matt.fleming@intel.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: mingo@kernel.org, x86@kernel.org, mjg@redhat.com,
        linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, hpa@zytor.com
Date: Thu, 04 Oct 2012 10:18:24 +0100
In-Reply-To: <506D4988020000780009F86E@nat28.tlf.novell.com>
References: <1349269157-25956-1-git-send-email-matt@console-pimps.org>
	 <1349269157-25956-2-git-send-email-matt@console-pimps.org>
	 <506C4C3A020000780008D041@nat28.tlf.novell.com>
	 <1349273028.7223.35.camel@mfleming-mobl1.ger.corp.intel.com>
	 <506D4988020000780009F86E@nat28.tlf.novell.com>
Organization: Intel Corporation (UK) Ltd. - Registered No. 1134945 - Pipers
 Way, Swindon SN3 1RJ
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2140
Lines: 47

On Thu, 2012-10-04 at 07:32 +0100, Jan Beulich wrote:
> >>> On 03.10.12 at 16:03, Matt Fleming <matt.fleming@intel.com> wrote:
> > On Wed, 2012-10-03 at 14:31 +0100, Jan Beulich wrote:
> >> >>> Matt Fleming <matt@console-pimps.org> 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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/