All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: "Li, Xin" <xin.li@intel.com>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	"Dong, Eddie" <eddie.dong@intel.com>,
	"Zhang, Fengzhe" <fengzhe.zhang@intel.com>
Subject: Re: [PATCH] iomem: Prevent Dom0 pci bus from allocating RAM as I/O space
Date: Mon, 21 Feb 2011 14:20:32 -0500	[thread overview]
Message-ID: <20110221192032.GC5041@dumpdata.com> (raw)
In-Reply-To: <FC2FB65B4D919844ADE4BE3C2BB739AD36B1ED05@shsmsx501.ccr.corp.intel.com>

On Mon, Feb 21, 2011 at 06:35:05PM +0800, Li, Xin wrote:
> I'm thinking how this issue happened.
> 
> For most devices, their MMIO resources are allocated in BIOS, thus it's ok for dom0 to use PFN as MFN, because dom0 is trusted.
> 
> However for devices like i915, whose drivers need to allocate MMIO when running in dom0, the issue Fengzhe is trying to fix may pop up, because dom0 kernel tries to allocate the MMIO resource from holes in its e820 table (not real hardware e820), which is RAM actually in below Fengzhe's case when limiting dom0 memory to a smaller value.

Found a nice back history of why this is needed: http://lwn.net/Articles/256335/ 
> 
> So for such cases the assumption of MFN == PFN is broken, possible solutions are:
> 1) use a hypercall to allocate MMIO from Xen/real hardware when dom0 allocates MMIO, also add the mappings into p2m of dom0.  But this needs to hack the dom0 driver when it tries to program the PFN into device.
> 2) Fengzhe's solution to mark hardware RAM as reserved in dom0's e820 table, to avoid conflict and make MFN == PFN true again.  No driver changes required.
> 

Fengzhe's solution works fine. I've tested it on a box with G33 chipset and it makes the boot
problem disappear (if I set dom0_mem=1500MB I would hit this, otherwise it booted fined).

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>


> I don't know if I missed something important here, please correct me if you find any.
> 
> Also any other proposals?

Also sticking this patch for 2.6.38-rc5 train.

I am going to rename the title of the patch to

"xen/setup: Inhibit resource API from using System RAM E820 gaps as PCI mem gaps."

and expand the description with snippets from this discussion.

Thank you for tracking this bug down and proposing a patch.

  reply	other threads:[~2011-02-21 19:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-16 14:26 [PATCH] iomem: Prevent Dom0 pci bus from allocating RAM as I/O space Zhang, Fengzhe
2011-02-16 15:06 ` Konrad Rzeszutek Wilk
2011-02-16 15:20   ` Konrad Rzeszutek Wilk
2011-02-16 15:47     ` Konrad Rzeszutek Wilk
2011-02-17  5:32       ` Fengzhe Zhang
2011-02-17 14:23         ` [PATCH] iomem: Prevent Dom0 pci bus from allocating RAM as I/O space in 2.6.32.27 tree Konrad Rzeszutek Wilk
2011-02-17 15:07           ` Li, Xin
2011-02-17 15:35             ` Konrad Rzeszutek Wilk
2011-02-18 15:16         ` [PATCH] iomem: Prevent Dom0 pci bus from allocating RAM as I/O space Konrad Rzeszutek Wilk
2011-02-20 13:58           ` Fengzhe Zhang
2011-02-17  4:11   ` Fengzhe Zhang
2011-02-18 22:05 ` Konrad Rzeszutek Wilk
2011-02-20 14:14   ` Fengzhe Zhang
2011-02-21 10:35     ` Li, Xin
2011-02-21 19:20       ` Konrad Rzeszutek Wilk [this message]
2011-02-22  4:55         ` Li, Xin

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=20110221192032.GC5041@dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=eddie.dong@intel.com \
    --cc=fengzhe.zhang@intel.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=xin.li@intel.com \
    /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 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.