[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Physical memory start contraints in the Linux kernel (Was: Re: Xen osstest on Calxeda midway progress (Was: Re: [xen-unstable test] 21486: tolerable FAIL - PUSHED))





On 11/12/2013 01:37 PM, Arnd Bergmann wrote:
On Tuesday 12 November 2013, Stefano Stabellini wrote:

Hi Stefano,

I haven't given it too much thought, but here is what I believe should
be done:

The question for you, as arm-soc maintainers, is: do you think this
should work and if we find any issues we should just fix them or report
them as bugs?

Modifying the DT to mark anything as "reserved" or absent that Dom0
should or can not touch sounds like the correct way to do this. Whether
this needs to be done by modifying the reg property of the device node
or through a different method I can't tell.

If you find bugs in the kernel that prevent this from working, but it
works fine for everyone else, it's up to you to provide a bug-fix,
which would most likely be up to Russell to apply.

Is this entirely going away with multiplatform kernels so we shouldn't
worry about it?

Multiplatform kernels are by definition relocatable using
CONFIG_ARM_PATCH_PHYS_VIRT, within some limitations such as the
granularity of the mapping. You certainly can't move the start of memory
to an address of smaller than 2MB (hugepage) alignment, but you might
need something larger than that.

During some debugging on the Arndale and Midway, I found another constraint with CONFIG_ARM_PATCH_PHYS_VIRT. I have noticed that all the kernel physical addresses must be lower than the corresponding virtual addresses. So the delta offset compute in __fixup_pv_table (arch/arm/kernel/head.S) must always be negative. If this assertion is not validated, when the kernel will browse the memory bank (sanity_check_info in arch/arm/mm/mmu.c), __phys(...) will compute a wrong address and will result to consider all memory bank as highmem.

After digging in the code, it seems it's due to some optimization during opcode fixup in __fixup_a_pvtable. Is it a wanted constraint?

Or is this a lost fight and should we find a workaround (see below if we
are curious) to make the start of memory look the same?

I don't see what hack you are referring to, can you elaborate?

My feeling is that we should maintain the requirement that that it must be
possible to enable Dom0 support on any virtualisation-capable platform
without breaking other platforms or causing an unreasonable run-time
overhead.

BTW, does Dom0 require an LPAE-enabled kernel or can it be a regular
non-LPAE ARMv6/v7 multiplatform build?

It can be both.

Cheers,

--
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.