From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: EFI boot Issue with setup_xenheap_mappings() Date: Thu, 9 Oct 2014 13:11:36 +0100 Message-ID: <1412856696.4463.10.camel@citrix.com> References: <5435CF8F.3010202@amd.com> <1412844670.3162.3.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1412844670.3162.3.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Suravee Suthikulanit Cc: Roy Franz , Stefano Stabellini , Julien Grall , Vijay Kilari , xen-devel List-Id: xen-devel@lists.xenproject.org On Thu, 2014-10-09 at 09:51 +0100, Ian Campbell wrote: > Yes, looking again at the arm64 setup_xenheap_mapping I think it is > pretty broken when facing non-aligned memory. I think it's just a > coincidence that EFI happens to expose this (by reserving/fragmenting > more memory), where u-boot based systems tend not to do so much of that > sort of thing. The key turns out to be that where u-boot/dtb presents all of the RAM in the memory node (which is generally aligned in h/w) and uses the dtb memreserve function to carve out holes EFI instead registers only the unreserved RAM to start with, which is more likely to be misaligned. It is legitimate for EFI to do things this way, so it needs to be fixed. I've now reproduced locally, including the fix to setup_xenheap_mapping resulting in an issue accessing the frame table. I'm still investigating, hopefully I'll have a fix today or tomorrow. Ian.