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@xxxxxxxxxx>
> 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.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home