mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	Vasiliy G Tolstov <v.tolstov@selfip.ru>
Subject: Re: [GIT PULL] Small Xen bugfixes
Date: Mon, 1 Nov 2010 16:36:28 +0000	[thread overview]
Message-ID: <1288629388.13236.4583.camel@zakaz.uk.xensource.com> (raw)
In-Reply-To: <4CCD9935.50308@goop.org>

On Sun, 2010-10-31 at 16:28 +0000, Jeremy Fitzhardinge wrote:
> On 10/31/2010 02:13 AM, Ian Campbell wrote:
> >> The 3rd is certainly simplest, at the cost of wasting a trivial amount
> >> of memory.
> > Doesn't Linux avoid using the lowest 1M anyway? (obviously apart from
> > the start of day probing for firmware tables etc).
> 
> No, it tries to use most of it I think.  It will tend to avoid the low
> 64k (maybe more) to avoid BIOS bugs.

It'll be interesting to see what effect Vista's avoidance of the whole
region (so I hear) has on BIOS vendors... (I think we can all guess)

> >>   Unfortunately it crashes early.  Sigh, will try and sort it
> >> out this afternoon.
> > Strange!
> 
> I didn't get a chance to poke at it again, but in retrospect, I think
> there are various "must succeed" allocations in low memory.  We don't
> need those allocations (things like AP boot trampoline, etc), but we
> don't bother to stub them out or prevent them from happening.  Reducing
> the system to one with *no* allocatable memory below 1M is just too
> strange, and would be a continuous source of problems in the future.

Agreed, we should try and mimic native as far as possible in this regard
or I fear we will see a never ending stream of little quirks and
oddities related to this sort of thing.

> Of the other two options, I think your original approach is going to be
> simplest.  E820 gap filling wouldn't be too bad, but we'd end up having
> to add a bit of gap-tracking logic to the E820 loop which isn't
> currently there.

It would also make us susceptible to perhaps being a bit fragile in the
face of unexpectedly insane e820s coming from the BIOS.

> Ignoring sub-1M gaps is simpler (and it needn't be
> conditional on xen_initial_domain(), because we would never expect to
> see anything strange sub-1M in a domU, and if there is, we should still
> be careful of it in case something odd is going on).

Absolutely.

I wonder if we shouldn't also do the following (note: untested). Since
Xen avoids using the sub-1M region for anything I think it is reasonable
to give the whole lot over to domain 0 for the purposes of finding
firmware table stashed in odd locations etc.

Ian.

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index ebb74ec..ab086e5 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -2321,7 +2321,7 @@ __init void xen_ident_map_ISA(void)
 
 	xen_raw_printk("Xen: setup ISA identity maps\n");
 
-	for (pa = ISA_START_ADDRESS; pa < ISA_END_ADDRESS; pa += PAGE_SIZE) {
+	for (pa = 0; pa < ISA_END_ADDRESS; pa += PAGE_SIZE) {
 		pte_t pte = mfn_pte(PFN_DOWN(pa), PAGE_KERNEL_IO);
 
 		if (HYPERVISOR_update_va_mapping(PAGE_OFFSET + pa, pte, 0))



      reply	other threads:[~2010-11-01 16:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-29 18:57 Jeremy Fitzhardinge
2010-10-29 19:08 ` Linus Torvalds
2010-10-29 19:20   ` Jeremy Fitzhardinge
2010-10-29 20:06     ` Jeremy Fitzhardinge
2010-10-31  9:13       ` Ian Campbell
2010-10-31 16:28         ` Jeremy Fitzhardinge
2010-11-01 16:36           ` Ian Campbell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1288629388.13236.4583.camel@zakaz.uk.xensource.com \
    --to=ian.campbell@eu.citrix.com \
    --cc=Xen-devel@lists.xensource.com \
    --cc=jeremy@goop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=v.tolstov@selfip.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®