From: Jeremy Fitzhardinge <jeremy@goop.org> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: "Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Ian Campbell <Ian.Campbell@citrix.com>, Vasiliy G Tolstov <v.tolstov@selfip.ru> Subject: Re: [GIT PULL] Small Xen bugfixes Date: Fri, 29 Oct 2010 12:20:17 -0700 [thread overview] Message-ID: <4CCB1E71.3060600@goop.org> (raw) In-Reply-To: <AANLkTi=g5sdiWSaLUHAATQn-1=jPqtc=RL6SpYSMYn98@mail.gmail.com> On 10/29/2010 12:08 PM, Linus Torvalds wrote: > On Fri, Oct 29, 2010 at 11:57 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> * fix dom0 boot on systems whose E820 doesn't completely cover the >> ISA address space. This fixes a crash on a Dell R310. > Hmm. This clashes with my current tree. Bugger, so it does. I just did a test merge with no complaint though; what happened? I'll redo the patch anyway to fix the below. > And that conflict is trivial to fix up, but the thing is, I think the > patch that comes from your tree is worse than what is already there. > > Why is that simple unconditional > > e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS - ISA_START_ADDRESS, > E820_RESERVED); > > not just always the right thing? Why do you have a separate hack for > dom0 in xen_release_chunk() instead? That just looks bogus. Yes, we actually had this discussion. I was for making the e820_add_region unconditional, and Ian's counter was that it could be done in the common code rather than Xen-specific. > The normal logic we use on PC's is to just always reserve the low 64kB > of memory, and the whole ISA space. Why doesn't Xen just do the same? The specific issue is that the Xen domain returns any memory that's not covered by an E820 entry back to Xen, mostly to make sure that memory isn't wasted by being shadowed by PCI devices. But it was also doing this in the sub-1M region, which on all the machines I've tested on is completely covered. But on a Dell R310 there's a little 2-page gap where some ACPI stuff is lurking, that was being released back to Xen so it couldn't be accessed from Linux any more. The fix is to just make sure the whole low region is covered (or at least the 640k-1M space). I'll rework the patch. Thanks, J
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org> To: Linus Torvalds <torvalds@linux-foundation.org> Cc: "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>, Ian Campbell <Ian.Campbell@citrix.com> Subject: Re: [GIT PULL] Small Xen bugfixes Date: Fri, 29 Oct 2010 12:20:17 -0700 [thread overview] Message-ID: <4CCB1E71.3060600@goop.org> (raw) In-Reply-To: <AANLkTi=g5sdiWSaLUHAATQn-1=jPqtc=RL6SpYSMYn98@mail.gmail.com> On 10/29/2010 12:08 PM, Linus Torvalds wrote: > On Fri, Oct 29, 2010 at 11:57 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote: >> * fix dom0 boot on systems whose E820 doesn't completely cover the >> ISA address space. This fixes a crash on a Dell R310. > Hmm. This clashes with my current tree. Bugger, so it does. I just did a test merge with no complaint though; what happened? I'll redo the patch anyway to fix the below. > And that conflict is trivial to fix up, but the thing is, I think the > patch that comes from your tree is worse than what is already there. > > Why is that simple unconditional > > e820_add_region(ISA_START_ADDRESS, ISA_END_ADDRESS - ISA_START_ADDRESS, > E820_RESERVED); > > not just always the right thing? Why do you have a separate hack for > dom0 in xen_release_chunk() instead? That just looks bogus. Yes, we actually had this discussion. I was for making the e820_add_region unconditional, and Ian's counter was that it could be done in the common code rather than Xen-specific. > The normal logic we use on PC's is to just always reserve the low 64kB > of memory, and the whole ISA space. Why doesn't Xen just do the same? The specific issue is that the Xen domain returns any memory that's not covered by an E820 entry back to Xen, mostly to make sure that memory isn't wasted by being shadowed by PCI devices. But it was also doing this in the sub-1M region, which on all the machines I've tested on is completely covered. But on a Dell R310 there's a little 2-page gap where some ACPI stuff is lurking, that was being released back to Xen so it couldn't be accessed from Linux any more. The fix is to just make sure the whole low region is covered (or at least the 640k-1M space). I'll rework the patch. Thanks, J
next prev parent reply other threads:[~2010-10-29 19:20 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-10-29 18:57 [GIT PULL] Small Xen bugfixes Jeremy Fitzhardinge 2010-10-29 18:57 ` Jeremy Fitzhardinge 2010-10-29 19:08 ` Linus Torvalds 2010-10-29 19:20 ` Jeremy Fitzhardinge [this message] 2010-10-29 19:20 ` Jeremy Fitzhardinge 2010-10-29 20:06 ` Jeremy Fitzhardinge 2010-10-31 9:13 ` Ian Campbell 2010-10-31 9:13 ` Ian Campbell 2010-10-31 16:28 ` Jeremy Fitzhardinge 2010-10-31 16:28 ` Jeremy Fitzhardinge 2010-11-01 16:36 ` Ian Campbell 2010-11-01 16:36 ` Ian Campbell
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=4CCB1E71.3060600@goop.org \ --to=jeremy@goop.org \ --cc=Ian.Campbell@citrix.com \ --cc=Xen-devel@lists.xensource.com \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.