Re: [PATCH 1/2] xen/mmu: Add workaround "x86-64, mm: Put early page table high"

[Daniel Kiper]

On Tue, May 03, 2011 at 11:12:06AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, May 03, 2011 at 02:55:27AM +0200, Daniel Kiper wrote:
> > On Mon, May 02, 2011 at 01:22:21PM -0400, Konrad Rzeszutek Wilk wrote:
> > > As a consequence of the commit:
> > >
> > > commit 4b239f458c229de044d6905c2b0f9fe16ed9e01e
> > > Author: Yinghai Lu <yinghai@xxxxxxxxxx>
> > > Date:   Fri Dec 17 16:58:28 2010 -0800
> > >
> > >     x86-64, mm: Put early page table high
> > >
> > > it causes the Linux kernel to crash under Xen:
> > >
> > > mapping kernel into physical memory
> > > Xen: setup ISA identity maps
> > > about to get started...
> > > (XEN) mm.c:2466:d0 Bad type (saw 7400000000000001 != exp 1000000000000000) for mfn b1d89 (pfn bacf7)
> > > (XEN) mm.c:3027:d0 Error while pinning mfn b1d89
> > > (XEN) traps.c:481:d0 Unhandled invalid opcode fault/trap [#6] on VCPU 0 [ec=0000]
> > > (XEN) domain_crash_sync called from entry.S
> > > (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> > > ...
> > 
> > I was hit by this bug when I was working on memory hotplug.
> > After some investigation I found myself above mentioned patch
> > as a guilty and later I discovered that you are working on that
> > issue. I have tested your patch and discoverd some issues with it.
> > First of all it has compilation issues on gcc version 4.1.2 20061115
> > (prerelease) (Debian 4.1.1-21). Details below.
> > 
> > Additionlly, I think that your patch does not work as you expected.
> > I found that git commit 24bdb0b62cc82120924762ae6bc85afc8c3f2b26
> > (xen: do not create the extra e820 region at an addr lower than 4G)
> > do this work (to some extent). When this patch is removed domU
> > is crashing with following error:
> 
> Which is "this patch" ? The 24bdb0b62cc82120924762ae6bc85afc8c3f2b26?

Yep.

[...]

> > I think that (Stefano please confirm or not) this patch was prepared
> > as workaround for similar issues. However, I do not like this patch
> > because on systems with small amount of memory it leaves huge (to some
> > extent) hole between max_low_pfn and 4G. Additionally, it affects
> > memory hotplug a bit because it allocates memory starting from current
> > max_mfn. It also breaks memory hotplug on i386 (maybe also others
> > thinks, however, I could not confirm that). If it stay for some
> > reason it should be amended in follwing way:
> > 
> > #ifdef CONFIG_X86_32
> >         xen_extra_mem_start = mem_end;
> > #else
> >         xen_extra_mem_start = max((1ULL << 32), mem_end);
> > #endif
> > 
> > Regarding comment for this patch it should be mentioned that without this
> > patch e820_end_of_low_ram_pfn() is not broken. It is not called simply.
> > 
> > Last but least. I found that memory sizes below and including exactly 1 GiB and
> > exactly 2 GiB, 3 GiB (maybe higher, i.e. 4 GiB, 5 GiB, ...; I was not able to test
> > them because I do not have sufficient memory) are magic. It means that if memory
> > is set with those sizes everything is working good (without 4b239f458c229de044d6905c2b0f9fe16ed9e01e
> > and 24bdb0b62cc82120924762ae6bc85afc8c3f2b26 applied). It means that domU
> > should be tested with sizes which are not power of two nor multiple of that.
> 
> Hmm, I thought I did test 1500M.

It does not work on my machine (24bdb0b62cc82120924762ae6bc85afc8c3f2b26
removed and 4b239f458c229de044d6905c2b0f9fe16ed9e01e applied).

Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/